夜雨聆风过去我们学东西，总有个固有逻辑：想做什么，先去学，打好基础，再找机会实习上手。
但有了AI之后，这个逻辑被彻底撞碎了。
我最近的一个疯狂念头是：做一个阅读器。按照传统的认知，这需要前端、后端、数据库……这一长串的名词，意味着至少得有个专业团队，或者自己苦学几年。可现在，AI直接把“编码”这块硬骨头啃下来了，原本高不可攀的逻辑构建，现在只需要我动动嘴。
这种“言出法随”的感觉让我沉醉，但随之而来的，是现实狠狠的一记耳光。
我在开发过程中，陷入了传说中的“Bug地狱”。UI改了一版又一版，Bug修了一个又一个。我发现自己就像个被困在莫比乌斯环里的苦力：程序生成只需5分钟，修改Bug却要10小时。豪情万丈的创作欲，在日复一日的报错日志中被磨灭得一干二净。
我开始怀疑人生：难道我还是要回归原点，去恶补编程、架构、工程知识吗？哪怕学会了，如果还是解决不了我的实际问题，那这些专业知识又有什么意义？
在那一刻，我突然意识到，我并不是缺编程知识，而是缺一套“管理机制”。
如果把开发软件看作一家公司，我不懂编程的领导，正在盲目地指挥着一群技术天才。当他们出错时，我不懂怎么看代码，只能干瞪眼。
所以我换了个思路：既然我不懂技术，那我就用管理学的思维，去解决开发里的“反馈缺失”问题。
我开始研究：AI前沿的人是怎么做的？最后我找到了一个关键词——Harness Engineering（反馈层/约束工程）。简单来说，就是给AI设定明确的“交卷标准”。你得告诉它：什么叫“做完”，哪里最容易出问题，出了问题怎么告诉我。
但这里又冒出一个致命难题：AI会谄媚，会有幻觉，我怎么知道它给的方案是对的？
既然要打败魔法，只能用魔法。我决定用AI去卷AI，压榨它，逼它内卷。
在参考了李笑来老师提到的“Claude与Codex互相评审”思路后，我搭建了一套“盲审+对抗式审核”的六步流程，这可能是我这辈子打过最富裕的仗：
第一步：Claude出草案。 让它作为唯一的构建者，给出初步方案。 第二步：独立盲审。 把方案同时发给Codex和Gemini，让它们完全独立地判断可行性。 第三步：设立“门卫”。 这是最关键的。如果两家有异议，必须打回第一步重做；只有两家都没异议，我才放行。这个“门卫”不需要懂技术，它只需要看通行证（是否有矛盾）。 第四步：多分身展开细节。 确立方向后，用Claude Ultra Code进行深入开发。 第五步：上下文对抗性审核。 这是“纠错”的核心。 第六步：综合拍板。 新开一个Terminal，请出Opus作为最终裁判。
很多人问我，第五步“对抗性审核”具体怎么做？其实秘诀全在于“改角色”：
不要用“帮我改进”这种温柔的指令，那只会换来AI敷衍的点头。你要明确告诉它：“你是来找茬的。你的任务不是帮我完善，而是证明这里有Bug。”
你需要把默认假设从“这里应该是对的”翻转为“这里一定有隐患”。如果AI找不到问题，千万别让它说“看起来没问题”这种废话，你要强迫它输出：“挑不出明显的，也要告诉我哪里风险最高。”
比如你可以直接这样写指令：“默认这里有问题，逐条挑刺，挑不出来也要说哪里最可疑。”
而且，必须在同一个对话上下文里做，一旦换了Terminal，上下文断了，AI就没法帮你逐行“找茬”了。
这套流程最爽的地方在于：你根本不需要精通编程，你只需要学会如何给AI当“裁判”。
当你不再纠结于每一行代码怎么写，而是学会了如何构建反馈机制、如何通过AI间的互相博弈来过滤幻觉时，你就会发现——
所谓的编程技能，其实正在变成一种可被调用的插件。真正核心的，是你作为一个“架构师”的视角：你如何定义问题，你如何构建这套对抗性的系统，以及你如何定位你自己。
别再被“我不会代码”的借口限制了。在AI时代，谁掌握了“管理AI”的能力，谁就拥有了构建世界的能力。
既然工具已经都在那里了，你最想解决的那个“真问题”，准备好让AI帮你搞定了吗？
