一些复杂的任务的 prompt 对经验和能力的要求感觉不比 coding 低

有同感。启用了 Agent framework ，agent loop 基本就是不可控的黑盒子，整个 agent 主要能力都由 system prompt 来控制。后续发现各种 case 不如预期的时候，只能各种微调 system prompt ，然后是不是符合预期就只能随缘。

终于意识到了。

这个现象的本质是信息论里的，计算不增加熵，不会生产更多的信息

说人话就是你需要用多少代码表达的细节，那就要用等量的 prompt 说出来。也就是你们说的等 prompt 敲完代码都要写完了

所以说 AI 基本上就是脱裤子放屁

当然，最好是伪代码...用什么库，用什么方法，数据流程，数据转换规则
这些都写在提示词里

@catazshadow 前面的描述是怎么得出后面的结论的？

“多少代码表达的细节，那就要用等量的 prompt 说出来”就算这句话没毛病，那还存在一个关键问题，prompt 是自然语言啊。代码是需要学习的。。。。

更别提 AI 在解决重复劳动上基本不需要说太详细的 prompt 。

@catazshadow 精辟。类似"期望路上遇到一个陌生人，一个眼神就让对方能知道你要让他去做一件复杂的事"一样不切实际

@xiaomushen 那就等于让初级开发做任务了，现在大家想要的是连架构设计都让 ai 来。一句话一个抖音全站就出来

目前写业务代码还是没完全交给 ai 基本上是写好大框架 然后框架里列好 todo 注释 比如 实现具体的查具体的数据 出来转换计算 这种重复的让 ai 来填充。和 ai 协作一起完成开发，这样改动范围可控，效率提升也明显。

@catazshadow 所以我现在每次只让 AI 生成具体的、一小段的代码，比如一个函数/class/一小段逻辑、有限范围且目的明确的重构，改动范围最多一两个文件。然后每次生成后都会尽量 review 一下。无法理解那种一段话让 AI 生成一整个项目，然后还嫌代码生成不够快的想法。

接 #8 ，或者是，我会自己定义好 golang interface ，然后写好一个 function 的输入输出，少量注释，参数用 interface 类型而非具体的 struct/struct 指针，然后 prompt 里明确说要做什么，这样效果非常好。AI 是一头猛兽，得让它以可控的、可预测的、受约束的方式工作，而不是像无头苍蝇一样乱飞乱撞。

@wnpllrzodiac 营销号们给个体户卖课，当然要画一个大饼呀

@catazshadow 有很多约定俗成的细节是不需要语言描述的，有很多场景其实人们并不关心怎么实现的，实现可能有 ABCD 很多种，人们只要结果，并不需要一定要用 A 方式实现。

可能在你看来 prompt 与代码的关系是文件与压缩包的关系，文件不能被无限压缩，但其实两者的关系并非如此。
AI 也并非单纯地凭借 prompt ，还有 mcp 、skills 、你的代码上下文等很多方面提供信息，所以大多数场景下只要你的 prompt 不是太简略，信息熵是足够的。

我理解 ai 解决了回字有四种写法难题。。。

@lscho #4

编程语言一定是比自然语言简单的。而且同样的逻辑场景，用自然语言说清楚，大概率是比代码更费劲。

@catazshadow #2 不需要等量。你的想法大概是想要输出一千行完美的代码，需要等量的完美自然语言描述作为输入，但实际上利用 agent/mcp/skill 大概只需要十分之一甚至更少，它们负责补充 prompt 、编程式地提供上下文信息，在一个较低的损耗下实现所谓的等量。
这需要一个共识，即自然语言本身能够元编程，AI 在编程上的发展证实了这一点。
OP 的疑惑在于本质复杂度是无法通过偶然复杂度进行消除，它们是编程这个概念本身的最小复杂度无法以任何手段进行删减，但 AI 确实能够减少达到最小复杂度所需的时间/精力，这是两码事。

了解下 spec coding

我发个自己写的可以一句话写网站的玩具，让大家玩玩，看看有多少人感觉有意思：

https://zhuyunpeng.qzz.io/

@shadowyue 没看明白我说的什么意思？代码再简单也需要学习啊。。。自然语言是个人都会。

而且人类学习自然语言的过程中，已经抽象出来很多概念，完全不需要再去描述细节。

比如让 ai 实现一个排序功能，自然语言只需要告诉他用冒泡排序就行了，难道还需要告诉他冒泡排序的实现过程？