从单句指令到Agent操作手册：我的Prompt工程实践记录

很长一段时间里，我对“Prompt工程”是抱有偏见的。

我总觉得只要把需求描述清楚、给AI设定个角色就足够了。网上那些错综复杂的提示词教程、所谓的“思维链（CoT）”，甚至“Prompt工程师”这个头衔，在我看来都有些过度包装。对于日常写写脚本的我来说，似乎真用不上那么复杂的玩法。

但最近在做一个体量稍大的个人网站项目时，这大半年重度使用各家AI的经历，让我彻底推翻了之前的想法。

各种AI工具的“脾气”与痛点

在实际的项目推进中，我几乎把主流的工具试了个遍，发现它们各有千秋，但也各有各的致命伤：

• Copilot (含CodeX)：代码补全很丝滑，但在IDE的Chat里，上下文经常莫名其妙丢失，很容易出现前言不搭后语的情况。
• Gemini 3.1 Pro (AI Studio)：方向性指导极佳。我通常用它来搭框架，写个初步的 Markdown 规划。但网页端的形态和额度限制，让它很难Hold住稍大的本地项目。
• Antigravity (调用Claude)：它的 Plan 模式非常惊艳，能把简单的 Prompt 扩写成完整的 Implementation Plan.md。从项目实施的完整性来说，它优于 Gemini。但致命伤是网络连接极不稳定，项目一大、需求一多就容易“歇菜”。

兜兜转转，最后的落地执行往往又回到了 VSCode 里的 Copilot Agent。现在我不再单纯把它当“自动补全器”或“百科全书”，而是直接让它去编辑、生成代码并 Debug。

但随着 Agent 接管的工作越来越多，三个让我非常抓狂的痛点开始浮现：

1. 版本管理的黑洞：虽然有回退功能，但极其不可靠。AI一顿操作猛如虎，改坏了很难干净地撤销（后来只能靠强迫自己高频 git commit 来续命）。
2. 长时记忆缺失与“补丁狂魔”：对话一多，Agent 就开始失忆。它在修改代码时，往往不顾及上下文的连贯性，更不会做架构级的更新。它最喜欢的解决方式是“打补丁”——头痛医头，脚痛医脚。
3. 简单问题复杂化：在没有足够约束的情况下，如果你技术路线给得不明晰，Agent 极容易把简单逻辑写得山路十八弯。代码行数激增，项目迅速腐化成“屎山”，重构和 Review 的成本高得吓人。

顿悟：从 Claude 源码泄露看 Prompt 的本质

转机发生在最近 Claude 系统源码（System Prompt）的泄露事件。阅读那些泄露的文档，包括前阵子爆火的“小龙虾”系统提示词，我突然意识到：高级的 Prompt 根本不是在教 AI 怎么说话，而是在给 Agent 注入全局的行为准则和约束条件。

结合我遇到的痛点，我开始尝试一套全新的工作流：

首先，我让 AI 扫描整个项目的核心代码，强制它输出一份《全局架构文档》。以前我觉得每次让 AI 读全量代码太费 Token，但现在我转换了思路——既然 Token 贵，那就让 AI 像人类程序员一样“做笔记”。架构文档一旦定好，这就成了项目的“宪法”。

我甚至给 AI 写了一套类似模板的约束规则：

• 每次更新代码前：必须先阅读并更新架构文档。
• 禁止无脑打补丁：遇到问题多从架构层面思考重构，而不是写 if-else 补丁。补丁打多了牵一发而动全身，不如一开始就在架构层解决。
• 操作规范：加新功能时，必须按照我给定的模板填写范围、约束、验收标准，并记录日志。

借助 Github Actions 和这套规则，我最终形成了一套 Copilot Repository Instructions。这相当于给 AI 配了一本《项目操作手册》。现在它在干活前，不仅要验证结构，干完活还要写更新日志。动作有迹可循，Token 消耗反而少了，因为它知道去哪里精准找代码。

架构不死：AI 时代的核心竞争力

在这个过程中，我最大的感触是：只要需求输入得当，规范文档（如 CLAUDE.md）设置好，AI 在具体代码的理解和实现上已经遥遥领先了。但是，AI 目前依然设计不好系统架构。

以前我们常说“架构重要”，现在我想说“架构是生死线”。

架构代表着高内聚、松耦合的系统性思考，它需要人类的经验、判断力和全局视野。一个架构混乱的项目，AI 只会越帮越忙，加速其屎山化；而一个架构清晰、模块化的项目，AI 能够如虎添翼。

未来核心工程师的价值，正在从“纯手工实现功能”转移到“设计出能让 AI 高效工作的系统”。系统设计、模块化封装、可扩展性……这些传统的“硬功夫”在 AI 时代不但没有贬值，反而变得比以前更值钱了。目前，AI 写测试用例非常神速，但梳理和定义那些扫描目录的功能、界定各个函数的边界，依然需要人脑来把关。

尾声：让想法先行

我最近才真正“悟”到这套大厂可能早已在用的工作流。但这个摸索的过程对我意义重大。

目前这套 Prompt 玩法还比较初级。未来如果涉足机器人开发或嵌入式系统，针对不同的工具链，肯定还需要制定专门的 Prompt 规范。如果是一个从 0 到 1 的全新 Idea，系统级提示词又该怎么写？这都是需要持续验证的。

最近我也在考虑搭建本地的大模型知识库（Wiki），把这些经验内化。下一步，我打算带着这套 Vibe Coding 的经验，去尝试一些机械、机器人相关的软硬件结合项目。

毕竟，写代码的门槛已经被 AI 踏平了，现在真正稀缺的，是那些疯狂而又严谨的 Idea。