AI辅助技术写作：何时停止

在一次C++代码维护中，作者发现了一条不断增长的注释，最终它比所描述的代码还要长。为了精简代码，作者决定使用Claude.ai将注释转化为一篇博客文章，并将解释从代码中完全移除。本以为事情就此结束，但后续的发展却出乎意料。

作者将草稿交给Google Gemini审阅，结果发现了一个真正的技术错误——不是风格上的小问题，而是一个实际的编程错误。Gemini提出了修复方案，但当作者尝试实施时，却发现代码无法编译。这意味着作者在代码审查中一直坚持的原始注释居然是错误的，而没有人发现，因为从未有人真正尝试编译过那个反例。

于是，文章从头重写。随后，作者又将其展示给更多的AI：Perplexity.ai、ChatGPT、微软Copilot等，但文章开始失控。每一轮审阅都会暴露出之前版本中细微的错误或未考虑的问题。新的术语被创造出来以区分原本不需要区分的事物；增加了一个白名单机制，以便特意选择运行时特性的快捷方式可以被标记为“已检查”而非“假定”。最终，文章从一条注释变成了一篇博客，又变成了一份类似实验室笔记的文件。

作者认为，这个过程中最值得记录的部分，是分歧的两种截然不同的类型，以及作者直到深陷其中才意识到它们的差异。第一种分歧有仲裁者。当AI说“我有更好的主意”而实际并非如此时，编译器能在十秒内解决争议。没有人需要被说服……代码要么能编译并按预期运行，要么不能。过程中的所有技术争议最终都以同样的方式解决：不是看哪个AI听起来更自信，而是通过实际验证。

第二种分歧则没有仲裁者。当技术内容已经扎实后，作者询问对文章本身的意见，却得到了截然不同的反馈。一些模型（尤其是ChatGPT和Copilot）认为文章太长（毕竟AI常被要求总结），而Claude.ai则认为长度合理，因为它展示了错误发生的过程，而非仅仅给出修正后的结论。没有人能通过编译来解决篇幅问题，因为这里不存在“指针是否被破坏”那样的客观事实。这不是事实性问题，而是关于文章目的的问题。结果发现，在意见开始交锋之前，没有人（包括作者）真正明确过文章的目标。

打破僵局的方法不是继续争论，而是回到原点，问自己最初想要达成什么。作者并非想写一篇在普通读者中赢得简洁评价的文章，而是想写一段可以链接到注释中的内容，供未来某天打开文件并好奇为什么这样写强制转换的人阅读。一旦明确了这一点，大部分关于篇幅的争论自然消散。但仍有一部分保留了下来：一些“过于冗长”的批评实际上是在命名问题上，而非篇幅问题。作者保留了那些正确的部分。

作者认为，可推广的经验是：当你无法判断一个分歧是技术性还是编辑性时，这种混淆本身就值得停下来并命名，因为两者需要完全不同的解决工具。一种需要编译器、实验或事实；另一种需要你大声说出自己真正想做的事情。当所有参与者（无论是人还是AI）在确认优化目标之前就急于优化时，这一点很容易被忽略。

“是否完成”没有编译器。到了某个时刻，你只能做出决定并继续前进。因此，在技术准确性达成共识后，作者决定停止修改。如果你觉得文章太长，需要总结，那就去问AI吧。🤖

如果你有改进本文的想法，欢迎在GitHub上提交问题（甚至更好的是提交拉取请求）！