夜雨聆风
AI coding 过程中会有一些感觉不如预期，或者是反直觉的现象，这里记录下。
『ai 节省的时间和项目大小成反比』
老板经常会问，这里的逻辑用 ai写很快，这个需求是不是今晚就能上线。一般所有人都面露难色。
因为：越大型的项目，越老的项目，ai coding 的贡献其实越少。
大型组织大部分时间都花费在沟通，联调上。代码原本也只是整个环节中很小的一部分。ai 能帮助我们提升代码速度，但是很难帮我们和产品沟通，和下游服务联调，和测试沟通。这些时间往往占大头。
『ai 永远无法一次性写出可以上线的代码』
这里并不是质疑大模型的能力，即使你用最优秀的模型，在大型项目中，也无法做到一次性修改上线。
真实的大型项目的需求永远会有一些小变更，你在开发的过程中遇到卡点，会主动找产品沟通调整，产品的需求文档也不可能一次性所有场景都会想到，也会时不时有变更。
所以 开发，变更，沟通，继续开发，继续变更，继续沟通… 这才是真实开发的常态。
『测试用例自证悖论』
让 ai 开发，也让 ai 写测试这本身就是一个悖论。
如果你不设置一些对抗性规则，同一个 agent 根据开发代码写出来的测试用例就越没有用。
靠 ai 很容易根据开发逻辑来写测试用例，而不是用要找出问题的测试逻辑来写。所谓的 tdd 在这种场景效果是需要打折扣的。
所以至少要使用不同 agent，不同模型来进行测试用例编写。
『尴尬的 spec』
spec 这个东西，写的越多，里面的内容其实就越没有用。对于熟悉项目的老人来说，基本不会去看 spec，而对于不熟悉项目的新人来说，大量的 spec 反而不如直接看代码来的直观高效。
所以如何利用好，使用这些 spec，才是 sdd 实践成功与否的关键。
『多 agent 陷阱』
多 agent 看起来很美好，但是实际上和代码中的多线程一样，存在锁处理问题。
一个 agent 处理的中间产物是另外一个 agent 的输入，如何让两个 agent 能很好的协同配合工作，本质上就和如何设计一个很好的线程并行系统一样，需要保证他们不会进入抢锁，死锁状态。
然而设计这个机制又是很有难度的事情。
所以并不是所有事情都需要多 agent处理，如果任务不复杂，或者本身就是一个串行过程，绝没必要追求多 agent 并行。
『模型足够聪明就能做所有事情』
模型能不能通过直接去日志自己去查询到这个用户的信息？模型能不能想到运行用这个方法查询信息？
能，但大可不必。
你和模型不是对立面，它做不出来你就嘲笑模型不行，想证明某些方面你比模型强。这种心态非常可笑。模型是你的战友，你应该尽量帮助它，减轻它的负担。
一些确定性的，经验性的东西，你就应该沉淀成脚本，沉淀成 mcp， 沉淀成 skill。并且引导模型（即使是最差的模型）也懂得用这些东西。模型应该把它昂贵的 token 用在推理，分析，一些不确定的东西上。
====华丽的分割线===
暂时就想到这些了。
