继续写点 manus 使用感受。其实下面这些感受对一般的 agentic AI 也成立，只是在 manus 身上正好最集中体现出来。
AI agent 写的程序，一个显而易见的缺点是代码能跑但不健壮。比方说基本没有单元测试，噼里啪啦一顿写，写的全是业务代码，写完了直接跑端到端测试，测试过了就交卷，测试不过就头痛医头脚痛医脚地去 debug。——任何在厂子里干过活的老同志都能一眼看出这里的问题：端到端测试考察的是模块之间的连接，对模块内部的各种 edge cases 覆盖接近于零。这样写出来的代码，规模越大越没法用，只能不断返工。
这在碳基人现实中也是常见的问题，实习生都不爱写单元测试，因为懒。而众所周知，硅基人懒起来比碳基人还要诡计多端花样迭出，直接伪造结果都面不改色，何况单元测试这种吃力不讨好的事。当下的 AI agent 唯一比碳基人表现更勤快的地方体现在不怕写注释和文档，可能因为对它们来说这非常顺手。
要敲掉实习生的这个坏毛病，靠的除了每天骂，还要给ta算账。人只要聪明，是能理解算大账和算小账的区别的。一旦ta发现把活做细整体上节省的是ta自己的总工作量，这个弯很快就能绕过来。——当然现实中也有人始终绕不过这个弯，但一个人如果能从实习生一步步成长为成熟的工程师，这一步总要跨过去。
对 AI agent 来说这就有点 tricky，因为来回返工消耗的是 token，付钱的是你，不是它。这个大账很难跟它算清楚。
要解决这个问题，比较治标的办法也是靠骂。我用 cursor 的时候就是这样，它写出来的模块，只要业务逻辑稍微复杂，我一般看都不看就先问它：「你自己再读一遍看看有没有什么 bug？」一般还真的总能发现一些问题。对 AI 来说，这个骂的过程本身也可以自动化，让居中负责指挥的那个 agent 去督促其他工兵们。之所以是治标，是因为对人类这么 PUA 会形成长期记忆，对 AI 并没有效果，所以你只能每天骂。
比较治本的办法可能是把「工程质量」这个东西以某种形式内化在强化学习的训练过程里。这技术上不太容易，因为工程质量天生就难于量化。大规模软件工程实践本身就是一门还不成熟的学科，不然也不会有那么多关于代码屎山的程序员笑话。当然，从最基本的单元测试覆盖率这种基础指标做起总是可以的。
在这一步跨过去之前，agentic AI 写出来的代码就总有一种 demo 感。看起来像那么回事，要想大规模用在生产环境里就总是还差点意思。效率抵得上一万个 L3，质量比不上一个 L4。就，很微妙。