背景：从年初到现在，我已经在工作中深度地使用了AI来辅助日常的工作，且都是公司的实际上线项目，在这个过程中和很多同事交流了一些思路和想法，也取得了长足的进步。
所以我认为是时候写一下对于这几个月实践的总结了。
主要矛盾：
我认为，当前的主要矛盾在于：AI 快速推进开发的过程中，代码的不可控性和线上项目的稳定性之间的矛盾。
对于和我一样打工的牛马来说，线上项目的稳定性无疑是最重要的，而稳定性受到整个开发过程中的多个环节的影响。这些环节可以分为：开发阶段、审核阶段、测试阶段、救火阶段（上线后）。
另一个维度是开发速度，在 AI 的辅助下，当前开发速度与去年相比已不可同日而语了，论坛中“你还在看代码吗？我已经 AI 一把梭哈了！”的言论也早已甚嚣尘上。
但是如果线上出了问题，你不仅要在家中紧急救火，还需要快速地定位问题，并及时反馈给其他部门。如果频繁地出问题，那不仅KPI会受到影响，甚至会因此丢掉工作。
这里我们需要讨论一个例外的情况：当前美国那边，仅需一个人把控方向和决策，由 AI 组成的开发集群也正在快速发展，前段时间国内火了一把的“一人公司”，也是基于这种思路，但这情况不在本篇文章的讨论范围内（等我再观察观察）。
所以，除了人工智能的辅助以外，“能工智人”如何可以把控开发质量和管理开发流程是至关重要的工程问题。
解决方案：
1. 写好 AGENTS.md
这个文件是各家 Agent 在和你开始对话时的默认基础，它会指导 AI 去快速地理解项目结构，而不是再去读取代码，如果这个文件中对于项目结构的内容写得比较好的话，是可以规避很多问题的。
就比如我碰到过很多次的，在一个维护了很多年的项目中，已经有针对某个模块的标准化的调用方式，但是某次会话修改代码的过程中，AI 会漏掉这些已有的规范，然后自己去造一个新的代码来实现同样的功能。
我的实践经验是，当发现出现了多次这样的问题时，在 AGNETS.md 中明确这个规范，往往是最简单有效的方法。
另外我在开发过程中，去参考了 DeepSeek Harness 的 AGENTS.md，借鉴和学习了他们的很多实践经验，感谢他们的开源。
2. 让“能工智人”理解代码
这个部分可能会有些争议，但我认为还是要写，因为这个部分涉及到的可能不止技术问题。
相信很多人在工作中都会经历一个考验，那就是你对自己开发的模块了解到什么程度。
不论是其他同事询问你具体的实现细节，还是开会解决问题时，是不是可以快速地给一个大概的结论，都需要考验你对模块的了解程度。
我在激进地使用 AI 推进项目的那个阶段，其实很多时间对代码的细节是不清楚的，我只能回答：“我去看看代码，一会给你答复。”
这可能会在有些时候显得你不太专业，尤其是线上出现问题，老板在工作群里询问情况，需要你快速解答时，回答的快慢，会是一个明确的信号。如果电脑就在手边，那么我们确实可以几分钟内就通过 AI 获得想要的结果，但是如果在会议室或者没有电脑的场景下，这就是一个难以办到的事情。
上面讲了一些“班味”十足的话，其实核心观点就是，我们该如何从需求中筛选出那些可能出问题的核心逻辑，把它记在脑子里，并丢给 AI 去实现。
我之前有和芬兰工程师共同工作了两年的经历，他们对分段提交、模块开发的极致要求确实影响了我对架构方面的思考。
这个分段提交在 AI 时代的价值是：可以帮助我，也就是“能工智人”，更快地熟悉代码。
其实就是需要把自己当做一个审核员，你需要做的是先自己思考，然后理解 AI 的实现，再检查它的问题或者学习它的思路，最终决定修改或者同意这个提交。
这其实和我年初对于 AI 发展对程序员工作影响的判断是一致的，因为在围棋项目中，已经经历了这个过程，AI 完全重塑了围棋的学习和训练方式，但这是题外话了。
3. 流程化
现在我需要讲一些更具体的问题了，也是我在开发中碰到的一些实际问题。
首先是注释，因为我的注释都是用中文写的，所以不管是 GPT 还是 Opus，我会经常发现他们在用一些混乱的中文写一些莫名其妙的注释，即使是 DeepSeek 也会经常出现这个问题。
另一个就是，即使我在 AGENTS.md 中写了对于某个问题的具体要求，AI 的实现还是偏离了正轨。
还会出现我只希望 AI 能修改A模块的问题，但是它扩大了这个修改范围，把B模块的代码也修改了，我检查以后又不得不还原这部分实现。
所以如果我们先把整个开发阶段拆成一个个节点，那么现在需要做的就是在这一个个节点中，再做一些细分。希望达到的目标是，在我们人工介入审核之前，可以尽可能地减少出错的情况，浪费不必要的精力。
这其实和前段时间看到的 A\ 的开发人员说的 Loop 思路是一样的，就是在一个大的任务中，做多次的循环检查，但现实的问题是，这可是要 Token 的啊！
排除成本问题，这个流程在我实际开发过程，确实解决了我所说的这几种问题，而且你可以针对每一项你认为必要的检查，都专门写一套清晰的规范，可以避免把这些内容全部塞入 AGENTS.md 中。
4. 单元测试
如果在 AI 时代之前，对于中小公司的开发者来说，写单元测试是一个奢侈的事情的话，现在这个时代，我认为这是一个标配了，我实在忍不住再吐槽一句，世界就是个大草台班子。
我需要先承认一个现实，单元测试的代码我其实是不看的，但是我认为他的价值是约束 AI 产出正确的代码。
这部分其实没什么好写的，但是我认为需要明确一个现实，就是即使单元测试都通过了，AI 的代码还是可能会出问题，业务的变化是快速和复杂的，总会给项目带来新的挑战。
5. 多模型互审
多模型互相审核代码，无疑是更加稳妥的方案，但是它还是涉及到一个具体的成本问题，从我的实践经验来看，最近几个月 GPT 的模型确实在发现问题方面，感觉有明显的优势，但是，最奢侈的做法，肯定是多个模型进行多轮的审核和修改。
我在实际的开发中也是这样做的，但是因为各家模型往往只能在自家的 Agent 软件上才能发挥出更好的效果，所以“能工智人”就需要扮演传话员的角色，每天在 Codex 和 Claude Code 之间复制他们的结论给另一边进行评估和修改。
不是我不想自动化（主要是差钱），而是在阅读他们发现的问题时，对个人来说，也是一个学习的机会，通常对于竞态、线程安全这些不好发现的问题，AI 审核确实有独特的优势。
总结：
以上所有内容，都是为了解决那个主要矛盾：
AI 快速推进开发的过程中，代码的不可控性和线上项目的稳定性之间的矛盾。
这些问题其实都是因为，当前大模型的内部运行对于人类来说，是个彻底的黑盒导致的。我们没有办法对过程进行干涉，所以只能在输入端和流程中进行工程化的控制。
如何把一个不可控的事情，尽可能地做到可控，我认为是当前 AI 使用过程中需要逐渐解决的问题。
这不仅对于程序员是个问题，对于现在各行各业接触和使用 AI 的人群也是问题。
这或许是未来一段时间的趋势吧。
题外话：就在今天早上，PHP 被披露了一个零日漏洞，链接，看上去非常严重。
就在我写下这段话的时候，我看到 Java 也出现了同样严重的漏洞，链接，真疯狂啊。
时代在滚滚向前，希望我能继续跟上它的脚步。