惊艳与惊吓
最近重度使用了一段时间的AI编码，基本上和AI创作，AI写ppt一样： 初一看，惊艳！仔细一看，错了，是惊吓！！
尤其是功能略微复杂一点点，需要多次迭代的时候，基本上就是一套石山嵌另一套石山，功能三分，垃圾五分，还有两分是莫名其妙的东东。
需求规格说明
当然，软件工程本身是个复杂的事情，开发质量不行，最终源头还是需求上，于是我们备足了需求规格说明。 有所改进，AI编码终于大致可用了。 但是也没能坚持多久，迭代次数一多，还是一堆垃圾。
从指令到协作
于是我们转为很礼貌的沟通方式。 每次不再是下指令，而是描述完需求后，补充一句：我说明白了么？ 就跟我们平常讨论项目时一样，不在把你明白没，你知道么，听懂了么挂嘴边，而是常说不知道我介绍清楚没。
这是一个很有效的改进方式，AI现在会更全面的考虑我的需求了。 看起来 AI 似乎也有了几分人性。 跟人有效的沟通，放到AI上，也一样生效。
走向正循环
事实上，这种方式只是稍微有所改善，但因为有效，所以我们进一步推进了这个机制，形成了一个三步法：
- 第一步，首先明确的提醒，在没有足够确定的理解的情况下，不得开始改代码。
- 第二步，描述具体的要求。
- 第三步，询问我是否介绍清楚了，有任何不确定的地方，随时问我。
这个机制目前实践下来，是个非常有效的机制，能大幅度减少AI堆积石山的情况。（这点不点名批评下某些AI编码助手，每次都迫不及待的的开始改代码，才说一两句就开始改。有时甚至靠揣测就动手改，不得不频繁的手动中断他的动作）。
就绝大部分普通情况而言，上述的机制能基本有效的推动AI编码朝可用方向发展。大致上是能持续进行的。（如果不用这种方法，基本上堆积的石山迭代个几次就能让AI都卡壳）
但对于一些要求高，流程略复杂，且不是通用流行做法的地方，仍不足以彻底解决问题。这个机制还可以更深次的发展一下。
首先，询问我是否介绍清楚了这个基操必须时时坚持。
其次，再碰到AI有误的时候，要求更改时，还得进一步询问，对于我的介绍，你是否有存疑的地方，需要我澄清的列出来。
最最重要的一点，碰到莫名奇妙的代码，要询问AI，你的理解是什么，你做出这个设定是基于哪个需求规格。
这种方式帮我们解决了一个隐藏的大祸根：我们在需求规格上定义的很清晰，但是在另一份数据字典 [^shujuzidian]的文档上，借助了AI来维护文档，AI更新字段说明时，按照常规的理解给了字段跟需求规格上定义不一样的含义说明。这个就导致了代码里偶尔就会出现奇怪的名词和跟名词对应来的思路和方法。
如果不是追根溯源的话，我估计这个软件及时再高明的AI，再多迭代几十次，也解决不了四处混乱的逻辑。
之前我们总以为给AI下指令就行，但到了复杂任务这里，我们不得不谦虚的认AI是个朋友，伙伴。 时长问他：这个地方是不是我介绍的不够到位？ 我的要求是否有遗漏或是不足之处？ 针对刚才的BUG我的需求规格是不是要完善一下？
到这里，基本上AI编码就能走向正循环了：不停的迭代能改进功能和代码。 具备了实际的生产意义。
沟通理论
回过头来反思下，我们跟AI沟通的提升，与跟人沟通的提升是完全类似的。只不过我们跟人沟通的效率，当时是看不出来的。这也实际导致了很多主导型的领导喜欢四处讲话，讲完顶多问句明白没，实际上没任何效果。 真人的沟通会困难很多，即便是友好的沟通，很多人也不会再被问到明白没时说不大明白。而且由于效果需要很长的时间才能体现出来。因此很难让人觉察到实际上是沟通出了问题。
跟AI不一样了，你沟通的不好，他的效果是直接且立刻的。你能看到AI频繁的辛苦的分析和创建代码，你也能看到他产出的是不是你想要的，有效的代码。 这种快速的反馈实际上就对我们的沟通能力的要求也就更高。
理论上来说，我们描述的需求，有两个维度的问题。
第一个维度是沟通中的信息丢失问题：我知道的 => 我表达的 => 对方接收到的 =>对方理解的。 每一层信息都有丢失和失真。 再跟真人协作的过程中，这个丢失和失真其实更严重，只不过作为人，人能熟练的掌握了另一门哲学：甩锅。 造成的不良后果，强调我已经发出来就行，只要不承担责任，就无所谓。
再跟AI沟通过程中，说实话，人的甩锅天赋仍是时不时的发作的。我们用AI开发过程中，基本上没有不骂AI的。（这里真诚建议下，如果以后有出AI实体机器人的，记得要加上钢铁护罩，一定要抗砸）。
但是骂AI他也听不见，就算是敲字骂他，他也没脾气，但对效果也没任何帮助。
这个维度导致的必然结果就是发现骂AI也没效果后，还得自己反思下自己是不是哪儿没说清楚。 要么你从沟通理论上学习到你自己要如何更好的表达，要么就是你使劲的骂AI，累死也无果后不得不自己想想是不是自己没说清楚。
另一个维度就是知识界限的维度。
用AI工具，有一个很好比喻：就是你是一个十年经验大专毕业的老师傅，领导给你配了一个清华硕士的实习生。你问实习生这个事情怎么干，他能从孔孟讲到爱因斯坦，从微观经济讲到世界大局，问无不答面面俱到。然后你让他去干个小活操作下，他能立刻给你搞出生产事故来。
怎么办？还得继续咨询他，仰仗他，但不得不随时盯着他。每一步就要仔细的审核确认。 这里我们有个比较独门的心得，就是做架构设计时，优先考虑切面模型，这种模型能做很好的隔离，避免错误的蔓延。然后就是对AI提要求时，提前让他做好测试。
就跟盯着清华硕士实习生干活一样，做一点确认一点。 而且AI的好处就是他不怕麻烦，所以尽可以放心大胆的要求AI，每个函数都写一个单元测试以确保该函数正常工作。 基本上这种一步一个测试的做法，就能很好的保证代码质量了。
理论上来说，我们掌握着领域知识，我们清楚自己要做的事情的业务逻辑，但是在专业知识上是无法和AI比拼的。而AI掌握着通用类的知识，他不知道我们想要的东西是什么样的，可能对我们细分领域也不是很了解。
这实际上比较良好的知识互补的情形。但是AI他不仅仅是知识，他还有创作能力。因此在这个过程中，既要全面的向AI介绍我们了解的知识，还需要借助AI的知识领域和创作能力，反馈，提示我们所不了解的知识，有时甚至是全新的创意。
这就是一个很完整的跟人互动的过程。
从奴隶到将军
最末，问下AI怎么想这个问题的。AI的回复是：不要把和AI的关系视为"主仆"关系，指令性的交互效果有限，而是要将和AI的关系视为朋友，伙伴，同事，共创伙伴，才能更好的发挥效果。
这不是观点，这是事实。你可以继续以主仆的方法操作AI，直到你撞的头破血流的时候不得不回到伙伴这种一下子就能更好的解决问题的方式上来。
可能这里你已经注意到，AI已经确定无疑的从仆从身份升级到平等得伙伴身份了。由此带来的下一步趋势思考，目前AI能力有限得情况下，人类已经不得不平视了。后续AI继续快速演化， 人类马上是不是不得不仰视AI，才能活得更好？
::: {#author name=reddish}
本文同步发表在 软件需求探索的https://srs.pub/thinking/vibe-coding-cooperation.html
作者: reddish@srs.pub
:::
[^shujuzidian]: 商业分析中的五十种分析方法和技巧之12-数据字典. https://srs.pub/babok/shuju-zidian.html
