#AI Coding

在大公司，个人对公司成长发挥的作用微乎其微，可以说基本为零。甚至个人对团队的贡献，有时候都是微不足道的。很多团队的存在意义，是维持这个系统的/正常运转，而不是创新。相反，如果你因为创新而引发了事故，那么你对团队的伤害往往远大于贡献。

在创业公司，每个人摊上的是大公司几个团队的活，如果不充分利用 AI 的 Coding 速度，根本不可能干完日常的工作。况且创业公司要么没赚钱要么赚的钱不多，而且创业公司的价值在于未来能赚多少钱而不是这个季度赚了多少钱，在这种情况下，走得快比走路姿势稳不稳重要的多……对于一份工作来说，我们当然要保证工作的完成质量，但因为大公司的代码量之大和审批流程之复杂，保证质量这件工作往往相当之无聊。如果环境允许你充分发挥自己的主观能动性，在质量与速度之间，发挥自己的审美和判断力来做取舍，这种工作的创造感其实远高于传统人工编码的时代，但也对实操人的素质提出了更高的要求。

这个时代由于编程的速度极大地提升，工作分配的颗粒度也大大加粗，上一个时代每个人分到的活可能只是写某个模块甚至是某个函数，你不需要关心最后大家工作内容合并做成的事情是什么。但是如今更多时候是要让你把某件事情做成。而做成一件事情可能分一百个子事情，AI 有能力做完每件子事情，但是 AI 没有能力决定要做哪一百件子事情，这个的上下文可能在老板与你的沟通中，也可能存在你历史积累的工作经验里，还可能是你生活的常识，甚至还可能要预测未来的发展。而 AI 完全没办法通过你聊天窗口那几句话知道这么多上下文信息。

我们和 AI 的区别在于，我们想把事情干成，AI 只想让这个对话完成。

1. 即使 AI 大幅提升了写代码的速度，产品本身的技术架构、分层、同类抽象，什么东西放到什么地方能够让后续更好地扩展和解耦，还是需要工程师本身的判断，这一块可以在项目第一个版本跑起来之后，就和你最好的 AI 仔细讨论，设定好对应的架构，并通过可沉淀可修改的文档记录下来，持续跟随项目迭代
2. 我平时更关心测试有没有覆盖那些容易想当然的地方，比如扫描结束以后文件又变了、进程检查失败、命令返回成功但 App 根本没有更新、旧任务很晚才回来覆盖了新结果。正常情况一般不难写，麻烦的是那些看起来没问题、实际上已经错了的情况，怎么及时发现它们
3. 特别是修 Bug 的时候，我会多留一些东西下来，除了把问题修复，还会加一个让旧代码失败的回归测试，然后沿着同类路径去找有没有类似的问题，最后把当时为什么这么改写到规则里面去
4. 测试能记住输入和结果，但记不住当时为什么放弃一种做法，所以项目里还有一批 Rules，主要记录功能边界、历史原因和不能碰的地方。比如为什么某类文件宁可漏掉也不能自动删除，为什么有些看起来重复的组件不能随便合并，哪些系统数据不属于 Mole。Rules 一多又很费上下文，我就按模块把它们拆开，只在改到相关代码时加载，再把经常重复的检查做成 Skills。bugs 会从以前的修复里找同类问题，design-system-review 看界面有没有越写越乱，release 则负责检查签名、公证、远端文件和更新链路，这样不需要每次都从头跟 AI 解释一遍
5. 还有一个对我很有用的法子，就是少做一些没有实际用处的功能。现在 AI 加一个设置项、兼容分支或者后台监听太容易了，几分钟就能写出来，留下来的状态和维护成本反而是腐化最大的原因。比如 Mole 现在给新功能定了一些规则，尽量不增加常驻开销，不增加新的特权和系统权限，有合理默认值就不继续加设置项，更新和清理也不会因为发现一种新的可能性就一直扩范围，很多功能是开发者自以为重要，使用者却完全不在乎的，还是建议从用户中来，到用户中去，如无必要勿增实体
6. 上面这些，假如说有什么特别的地方，我能想到的就是执行流程完全没有我插手干扰，每一步都由 AI 自动执行和验证，出错了 AI 自动去解决，只不过会在不同的时候设置必要的流程卡点，让 AI 主动去验证，得到明确的结果才确定通过，并持续迭代规则，保持现有规则的新鲜度，及时移除旧的逻辑，让校验逻辑和业务代码同步升级。

或许这就是 AI 时代的工程师更需要培养的能力，如何让 AI 写的代码更好维护、更清晰、更好扩展，即使半年、一年、两年都不会腐化，而且会越来越听话，越来越符合开发者的心意，也给多 Agent 合作开发打下一个比较稳的根基。之前手写代码的乐趣已经没有了，好在这件事弥补了一些纯 AI Coding 过程的无聊，让工程师的专业度得以延续下去。