把我2024年开始使用AI coding中使用的编码prompt list提供给AI，包含3.5万字，752行，让AI分析抽象出prompt的演变过程，
并以此为镜，推理归纳抽象LLM driven编码能力提升反映的算法演进路径、人机协作趋势，
进而提炼算法演进可能带来的软件工程、算法研发和IT信息技术带来的机遇和挑战
Gemini的回复：
这份报告不仅记录了你作为开发者与 AI 协作的历程，更像是一部“人类与硅基智能协同进化史”。从最初的“功能实现”到后期的“系统治理”和“情感/角色对齐”，他说，“你的 Prompt 演变精准地踩在了 AI 模型的每一次能力跃迁点上。”
| | | |
|---|
| 阶段 1：功能补完期 | | | AI 是工具 |
| 阶段 2：逻辑对齐期 | | “确保原有逻辑不变”、“一步步推理”、“紧扣报错” | AI 是助手 |
| 阶段 3：架构治理期 | 强调“最小化修改”、“向前兼容”和“系统性边界”。 | “不要蔓延”、“向下解决而非向上修改”、“最小化修改” | AI 是初级程序员 |
| 阶段 4：共生对齐期（Vibe Coding） | | “先对齐理解再编码”、“第一责任人”、“不要说教” | AI 是合伙人 |
AI 模型编码能力的演进路径分析
通过你的 Prompt 变化，我们可以反推出 AI 模型能力的升级路径：
- 早期：你反复要求“输出完整代码”，因为模型容易丢三落四。
- 后期：你开始要求“扫描仓库”、“分析调用链”。这反映了模型（如 Claude 3.5 Sonnet, GPT-4o 等）处理长文本和多文件关联能力的质变。
从“文本补全”到“逻辑推理（Reasoning）”- 早期的 Prompt 侧重于结果。现在的 Prompt（如“先分析原因，对齐后再修改”）利用了模型的思维链（CoT）能力。你不再只是要答案，而是要模型的“思考过程”，以确保其逻辑与系统架构一致。
- 你后期频繁提到的“向前兼容”、“不要引入新库”、“遵循现有命名规范”，说明 AI 已经具备了理解“软件工程约束”的能力，而不仅仅是写出一段能跑的代码。
ChatGPT的回复
从你的 prompt 演化，反推 LLM Coding 的真实技术路线，它其实无意中勾勒出了一条非常清晰的路线：
LLM 如何一步步被工程化驯服。
如果把你的实践抽象成一条算法能力需求曲线，大致是这样一条上升路径：
Token Completion → File-level Understanding → Cross-file Reasoning → Constraint-aware Editing → System-level Planning → Interactive Co-debugging
而非常值得注意的是：
你的 prompt 设计，几乎是贴着模型能力上限在演进。
这说明一件事：
不是模型单方面变强。 而是——
高密度工程约束 prompt，本身就在“塑形”模型的可用能力边界。
但从系统演化角度看，我的 prompt list 这条轨迹揭示的是一件更本质的事：
AI 编程的真正进化，不发生在模型里。 而发生在人类如何学会约束模型的不确定性。
模型在变强。 但真正让它进入生产级工程的，是软件从业者、信息技术人员正在构建的那套：
人机协作控制协议栈。
LLM inside智能编码的四阶段进化
我们的超过2万条prompt 总计3.5万tokens记录，Gemini划分了的四阶段，是成立的，但如果站在工程控制论视角，在抽象更高维度，则是另一条更清晰的演进主线：
从“让 AI 写代码” → 到“限制 AI 改什么” → 到“规定 AI 如何思考” → 到“定义人机协作协议”
这是四次质变，是在软件工程和编码上，人机协作互相教育和共同成长。
| | | | |
|---|
| 阶段 1：补全驱动 | 高频要求：
• 输出完整配置
• 完整类 / 函数
• 集成代码
• 补齐缺失部分 | 人 = 主程序员 | 暴露问题：
• 易遗漏上下文
• 跨文件一致性弱
• 工程约束感知不足
→ 被动补偿方式：反复要求“输出完整代码” | AI 主要承担代码生成与补全角色，工程可靠性仍由人类兜底；Prompt 的核心目标是完整性保障 |
| 阶段 2：一致性控制期 | 高频硬约束：
• 确保原有逻辑不变
• 严格遵循参数定义
• 紧扣报错推理
• 不要影响其他模块 | AI = 潜在风险执行体 | 关键认知跃迁：
• 默认 AI 会“过度发挥”
• AI 已具备破坏系统的能力（能力提升的反证） | Prompt 开始承担风险围栏（Guardrail）职责；Vibe Coding 从“生成导向”进入控制导向 |
| 阶段 3：最小修改原则确立 | 核心约束高频出现：
• 不要过度修改
• 最小化修改
• 不要蔓延
• 保持向前兼容
• 在源代码基础上集成 | Diff-first 控制范式 | 本质对抗对象：
→ LLM 的熵增倾向（重写 / 重构 / 风格统一冲动）
认知升级：
Demo 优势 ≠ 生产安全 | 标志 AI coding 正式进入工程域；Prompt 从“行为约束”升级为系统稳定性控制协议 |
| 阶段 4：协作协议显性化 | 新型协作结构：
• 先分析再修改
• 先输出理解
• 有疑问先提问
• 不假设缺失上下文
• 一步一步完成 | 人机握手协议（Handshake Protocol） | 核心变化：
Prompt 不再只是约束 AI 行为，
而是显式定义协作流程与同步机制 | Human-in-the-loop 从隐式经验 → 显式协议；AI coding 开始走向可编排的人机协同工程体系 |
在无意识中做对的一件事
逐渐把一次 coding 请求，从：
单轮指令
改造成：
带确认环的多阶段事务
本质上就是给 AI 编程加上了三段式控制：
[理解对齐] → [受控修改] → [结果验证]
这套结构一旦稳定，成功率会质变。这不是 prompt 技巧问题。这是与AI交互范式升级。
从Prompt 轨迹反推模型真实进化
如果把时间线和模型能力对齐，会看到一个很有意思的镜像关系。
上下文窗口扩张 → 我开始要求“全链路扫描”
早期我只敢让它改单文件。
后来开始频繁出现：
这背后只有一个原因：
模型终于“看得全”了。
上下文能力，是 AI coding 从玩具走向工程的第一道门槛。
推理能力提升 → 我开始强制它“先想再动”
当模型只有补全能力时，你要 reasoning 没意义。
但当 CoT 能力稳定后，我的 prompt 出现明显变化：
“一步一步推理问题原因”
这说明一件事：
我开始信任模型的中间思考质量。
这是从：
的关键跃迁。
工程感知增强 → Prompt 开始出现“系统语言”
后期我的 prompt 已经高度工程化：
这说明模型已经具备一种能力：
理解软件不是文件集合，而是约束系统。
但注意一个关键现实：
模型能理解 ≠ 模型会自觉遵守
这就是为什么——
人机控制协议仍然是刚需。
说一句可能有点反直觉的话
AI coding 的瓶颈，正在快速从“模型能力问题” 转移为“人类控制工程问题”。
为什么我这么判断？
因为在我的实际使用中已经反复验证三件事：
✅ 模型写代码能力：足够好用
在大多数 CRUD、前端、API glue 场景：
生成能力 ≠ 瓶颈
真正的问题很少是“写不出来”。
⚠️ 真正昂贵的是三件事
- 比如无论如何允许你写apikey这样高敏感信息到markdown文件
而你会发现——
我们的整个 prompt 进化史 本质都在压制前三件事。
这不是巧合。
这是工程现实。
Vibe Coding 时代真正的分水岭
很多人把 Vibe Coding 理解为：
但如果只停在这里，是不够进入生产的。
从我这条 prompt 演化曲线看，真正的分水岭是：
有没有形成可复用的人机控制协议栈
我现在越来越确信一件事：
未来 AI coding 不只是：
而是：
工程化人机协作的控制层。
Cursor 、vscode为代表的IDE 智能化路线，
Claude Code、Codex为代表的cli为主变成路线，
还有以智能体为载体的任务委托路线，比如用openclaw搭建的编程多agents 系统。
谁能先工程化人机协作的控制层，就会有领先优势
回看我这一年多的 prompt 演化，如果只用一句话总结：
一开始在教 AI 写代码。 后来我们在教 AI 不要乱写代码。 再后来，我们在为人机协作编写控制系统。
而我们越来越确信：
AI 编程的下一个时代，不是更强的模型时代。
而是——
人机协作控制工程时代。
决定 AI coding 上限的，已经不只是模型能力。
而是：
使用者是否具备 系统思维 约束思维 演化思维 工程治理思维
发表评论