夜雨聆风01
STRUCTURED PROMPT
Prompt 是带“结构”的参数，不是随意闲聊
从这份代码所呈现的组织方式看，每次对话并不是一整坨自然语言直接丢给模型，而是被拆成不同角色和来源的信息：系统提示、用户上下文、工具结果、历史记录。这些信息承担不同职责，也会在不同阶段被重新组织。
系统提示、用户上下文、工具结果与历史记录共同构成输入结构
这点很重要。很多人使用 AI 时，会把“背景、任务、限制、输出格式、验收标准”全写进一段话里，然后期待模型自己分辨什么最重要。对于简单任务问题不大，但任务一复杂，信息之间就会互相抢注意力：背景说明太长，真正目标被淹没；限制条件放在末尾，模型执行到一半才“忘了”；输出格式写得模糊，最后得到的结果难以直接使用。
结构化 Prompt，不等于写得更长
更好的做法，是把输入写成几个稳定槽位。你不需要每次都套一个几十行模板，只要把关键信息分清楚，模型就更容易保持任务边界。
目标：这次到底要完成什么，最终交付物是什么。
上下文：当前项目状态、已有代码、已经做过哪些尝试。
约束：哪些文件不能改、哪些接口必须保持兼容、时间或性能边界是什么。
输出：希望它直接改代码、先给方案，还是只返回 diff／checklist。
验收：什么结果算完成，例如测试通过、接口不变、只修改指定模块。
一个简单例子
与其说“帮我把这个接口优化一下”，不如说：“目标：降低这个接口的重复查询；范围：只改 service 层；约束：不改数据库表结构和 API 返回字段；输出：先说明瓶颈，再给最小修改方案；验收：现有测试必须继续通过。”
启发：与 AI 对话越结构化，结果越稳。“当前问题是 X，期望结果是 Y，约束条件是 Z”永远好于“帮我改下这个”。所谓 Vibe，不等于随意；流畅的体验背后，需要坚实的骨架。
02
STATE MACHINE
AI 工具本质是状态机，而非“一问一答”
源码里的 Agent 循环非常直接：用户输入 → 调用工具 → 结果回填 → 继续循环。这意味着一次“回答”并不是终点，而只是状态推进中的一个节点。
Agent 循环：输入、调用、回填、继续
这和传统聊天机器人最大的不同，是 Agent 会把外部世界重新带回模型：它读到一个文件、运行一次命令、拿到一个报错，这些结果都会成为下一步决策的新输入。于是，真正决定任务能不能走到最后的，不是第一步计划有多完美，而是每一步之后能不能根据新信息继续调整。
复杂任务应该按“可验证步骤”推进
如果你一次让 AI “从零重构整个项目”，它必须同时记住架构、依赖、命名、测试、异常处理和大量隐含约束，任何一步偏离都可能在后面放大。更稳的方式，是让任务天然形成检查点。
先观察：先读相关文件和依赖，不急着改。
再计划：明确准备动哪些位置，以及为什么。
小步执行：一次只完成一个可验证修改。
立即验证：编译、测试、lint、接口调用，能跑什么就跑什么。
根据结果继续：把真实结果回填，再决定下一步。
这也是为什么很多时候，“先跑起来 → 再调整 → 再优化”比“一次生成最终答案”更靠谱。工程任务的真相不是静态写在 Prompt 里，而是在执行过程中一点点暴露出来的。
启发：别总想着写出“完美的一键 Prompt”。把大任务拆成小步骤，每一步都能验证。先跑起来，再调整，再优化。这才更像一个稳定的工程工作流。
03
CONTEXT MANAGEMENT
上下文是最贵的资源，必须主动管理
这份代码分析里能看到一整套围绕上下文压缩和整理的机制，例如 microcompact、autocompact、context collapse。背后的问题很朴素：上下文不是越多越好，信息堆得太满，真正重要的信号反而会被稀释。
压缩聊天记录，把有效结论固化为 context.md
很多人会把上下文窗口理解成“AI 的记忆容量”，于是下意识觉得：只要把所有历史都塞进去，模型就会越来越懂项目。实际使用中往往相反。旧讨论、失败尝试、过期方案、冗长日志都会持续占据注意力，让模型很难判断“现在真正有效的事实”到底是什么。
把上下文分成三类，管理会轻松很多
稳定事实：架构约束、接口契约、技术选型、命名规范。这些适合固化到 Markdown／README／AGENTS 等长期文档。
临时工作信息：某次报错、某段日志、某个中间结果。任务结束后就应该退出主上下文。
当前焦点：这一步正在解决的问题，只保留真正影响下一步决策的信息。
从这个角度看，“开新会话”并不一定意味着丢失进度。只要你把已经确认的结论写成可复用的项目记忆，新会话反而像一次干净的上下文重启：噪声被清掉，但关键事实仍然保留。
实用习惯
每完成一个阶段，让 AI 把“已确认结论／未解决问题／下一步／禁止改动项”压缩成一段短 Markdown。后续换会话时只带这段摘要和必要文件，比把几十轮聊天完整继承下去更稳。
启发：聊得太长，就果断开新窗口。把架构、选型、约束写成 Markdown 固化下来，每次喂给 AI，而不是全靠它自己记。需要时用 /clear 清理上下文，也是一种主动管理。
04
PERMISSION BOUNDARIES
工具代表“带权限的能力”，没有边界必翻车
在工具层的设计里，重点不只是“这个工具能不能调用”，还包括权限检查、中断机制、结果体积上限等执行约束。对于真正能读写文件、运行命令、访问外部资源的 Agent 来说，能力越强，边界设计就越重要。
工具是能力，权限与约束决定了能力的边界
这是从聊天走向自动化时最容易被忽略的一层。模型本身也许知道“应该怎么做”，但工具权限决定了它实际上“能够做多大”。如果任务范围没有被收窄，Agent 为了完成目标，很可能顺手修改它认为相关的其他代码；从模型视角看这是积极解决问题，从工程视角看却可能是不可控的副作用。
给 Agent 派活，最好同时定义四个边界
文件边界：允许读哪些目录，允许写哪些文件。
动作边界：可以改代码，但是否允许安装依赖、删文件、执行数据库迁移。
结果边界：一次输出多少内容、一次最多改多少文件，避免修改面失控。
停止条件：遇到测试失败、依赖缺失、权限不足时，是继续猜还是立即停下来汇报。
把“帮我重构项目”改成工程任务
“只修改 src/service/order.ts 中的查询逻辑；不改 API、数据库 schema 和其他文件；修改后运行现有单测；如果测试失败，不要继续扩散修改，先返回失败原因。”
启发：给 AI 派活，权限要极度收敛。与其说“帮我重构项目”，不如说“只改这个文件里的这个函数，不要动其他地方”。Vibe coding 翻车，很多时候不是模型不行，而是我们给的权限太模糊。
05
GRACEFUL RECOVERY
优雅降级：保住结构比直接崩溃更重要
这份代码分析还体现出一个很工程化的思路：中途出错时，尽量保住已有消息链、已完成状态和可继续执行的结构，而不是因为一个节点失败就把整条链路推倒重来。
工具失败后保留已完成状态，从局部恢复继续推进
这其实就是“优雅降级”。在真实开发里，失败不是例外，而是常态：命令可能超时，某个工具返回空结果，依赖可能缺失，测试可能只坏一条。成熟系统不会假设所有步骤都一次成功，而会提前设计“出错之后还能怎么办”。
遇到失败，先问四件事
失败发生在哪个节点？先定位最小断点，不要泛化成“整个方案都错了”。
之前哪些结果仍然可信？保留已经验证通过的修改和结论。
能否绕过或替换当前步骤？例如换一个工具、缩小输入、改用手动确认。
恢复后从哪里继续？明确新的起点，而不是重新生成整套方案。
这也是“局部修复”比“全部重写”更有价值的原因。每一次全量重写，都会重新引入变量；而最小修复能最大程度保留已经验证过的部分，让错误范围保持可控。
真正稳定的 AI 编程流程，不是“从不出错”，而是“出错之后仍然知道自己在哪、已经完成了什么、下一步应该怎么恢复”。
启发：项目跑不通时，别一生气就推倒重来。让 AI 先定位最小断点，修那一处，把已经验证过的链路保住。“局部修复”而不是“全部重写”，这才是工程师思维。
∞
WORKFLOW
把这 5 条串起来，就是一套可复用的 AI 编程工作流
如果把前面的观察放到一起，会发现它们并不是五个孤立技巧，而是一条完整链路：先用结构化输入明确任务，再让 Agent 小步执行；执行过程中持续整理上下文；每个工具只开放必要权限；一旦失败，就从最小断点恢复。
从 Prompt 到工具链，AI 能力落地依赖工程化骨架
一套可以直接照着用的顺序
1．先定边界：目标、范围、禁止事项、验收标准先说清楚。
2．先读后改：让 AI 先理解相关代码和依赖，输出修改计划。
3．一次一小步：每次只做一个可以验证的改动。
4．每步都验证：测试、编译、运行结果直接回填给 Agent。
5．定期压缩上下文：把稳定结论固化，把噪声和失败尝试清出去。
6．出错就局部恢复：保留已验证部分，只修最小断点。
你会发现：当这套流程跑顺以后，真正提高效率的往往不是“模型突然更聪明了”，而是你把任务环境变得更清晰、更可控。模型能力没有变化，但有效输出会明显增加。
写在最后
源码给我们上了最生动的一课：Claude Code 更像一个需要我们提供结构、边界和上下文的“超级执行者”。AI 可以很聪明，但工程系统不能只靠聪明。真正把模型能力转化成生产力的，是外面那套看起来并不性感的工程机制。
Vibe Coding 的天花板，取决于我们给 AI 画的那个“框”有多清晰。Prompt 只是入口，后面真正决定结果的，是任务拆分、反馈循环、上下文治理、权限控制和错误恢复。
所以，所谓“Vibe Coding 的尽头是工程化”，并不是说以后不能凭感觉写代码，而是说：探索阶段可以松，交付阶段必须紧。越接近真实项目、越接近生产环境，就越需要把模糊的意图转化成明确的状态和边界。
真正能落地的 Vibe Coding：结构化表达，胜过随意提问；小步快跑，胜过一次性重写；持续验证，胜过相信“看起来没问题”；收敛权限，主动管理上下文；出错时保住已经验证过的部分。把这些基础工程做好，AI 才会从“灵感玩具”变成稳定生产力。
