1. 为什么只是“能用”还远远不够
刚开始用 AI 辅助开发时，我最关心的是它能不能把任务做出来：写一段代码、改一段文案、生成一个页面、整理一份资料。 但任务一多，问题就暴露出来了：同样的需求第二次怎么复现，输出不稳定时该改提示词还是改输入，哪些内容必须人工复核，最终版本应该存在哪里。
如果这些问题没有整理清楚，AI 工作流就会变成一堆聊天记录。短期看很快，长期看很难维护。 我希望它像代码项目一样，有输入、有过程、有产物、有复盘，而不是每次都从一句“帮我做一下”重新开始。
2. 先把流程拆层，别把所有逻辑都塞进一个提示词
我后来把工作流粗略拆成五层：资料准备、任务说明、模型生成、结果整理、人工确认。 这几层分开以后，调试就轻松很多。结果不准确时，我能判断是资料缺失、指令不清、模型理解偏了，还是后处理没有做好。
workflow/
├── inputs/ # 简历、项目说明、截图、参考站点
├── prompts/ # 可复用任务模板
├── drafts/ # AI 生成的初稿
├── reviews/ # 人工修改记录
└── outputs/ # 最终发布版本3. 给每类产物单独建目录，后面查问题会轻松很多
我现在不再把输入文件、生成结果和最终稿混在一起。比如优化博客时，简历、GitHub 项目、参考网站、文章草稿和最终 HTML 应该分开放。 这样以后想追溯“这段介绍为什么这样写”，就能回到当时的输入和修改记录。
inputs/放真实资料，例如简历、项目列表、已有页面。prompts/放稳定的任务模板，避免每次临时组织语言。drafts/保存模型初稿，方便比较前后版本。reviews/记录人工删改、事实核验和待确认内容。outputs/只放准备发布或交付的最终结果。
这种分层看起来像“多此一举”，但只要项目迭代两三次，它的价值就会出现：你不会再分不清哪个版本能发布，也不会把未经核验的内容直接放到线上。
4. 提示词也要像代码一样能被追踪和调整
我现在不太相信万能提示词。更可靠的做法，是给不同任务维护小而清晰的模板：写博客是一套，改简历是一套，生成部署脚本又是另一套。 每个模板只解决一类问题，修改时也能知道改动影响在哪里。
角色：你是一个技术博客编辑。
目标：保留作者真实经历，补充结构、背景和可复用步骤。
约束：
1. 不虚构公司、奖项、项目结果。
2. 命令和配置必须可解释。
3. 不确定的信息标记为待确认。
4. 输出要适合直接发布到个人博客。这样的模板比“帮我写得高级一点”可靠得多。它把边界提前说清楚，也能提醒我：AI 可以整理表达，但事实归属和最终判断仍然要由人来确认。
5. 人工校对不是补丁，而是工作流的一部分
我不会把模型输出直接当最终结果，尤其是涉及简历、技术方案、服务器配置和项目经历时。 这些内容如果写错，不只是表达问题，还可能影响可信度，甚至带来安全风险。
- 事实性内容要对照真实资料：学校、时间、项目名、仓库名、证书和奖项。
- 技术命令要能解释用途，最好经过实际验证。
- 涉及服务器的内容要避免暴露密码、密钥和过细的敏感配置。
- 最终语气要像自己写的，而不是像模板套出来的。
对我来说，AI 更像一个能加速整理的人，而不是替代最终责任的人。它适合扩展思路、生成初稿、检查遗漏，但最后一定要有人把关。
6. 当迭代成本下降以后，AI 才真正开始变得有价值
我后来最明显的感受是，效率提升不来自某一次惊艳输出，而来自每次调整都有抓手。 需求变了，就改输入；结构不顺，就改模板；事实不确定，就标记待确认；输出太散，就把任务拆小。
一旦工作流被理顺，AI 就从“偶尔帮忙的工具”变成“长期可用的协作层”。它不会替我决定技术方向，但能帮我更快整理资料、更快形成初稿、更快发现遗漏。 对个人博客、项目文档和学习笔记来说，这种稳定的协作方式比一次性的炫技更有价值。