问题背景
这类问题常见于团队刚开始把 AI 放进真实交付流程的时候。最容易出错的地方不是模型不够聪明，而是输入信息太散、验收标准太模糊、人工复核的位置太晚。
把现有组件代码和 CSS 约定作为参考，比描述“好看一点”可靠。 这篇文章更关心落地细节：怎么拆问题、怎么写代码或流程、怎么验收，而不是停在概念介绍。
实践里可以把 AI 当成一个速度很快但需要上下文的同事：它适合帮你整理材料、补齐边界、生成初稿，但不应该替你承担最终判断。越是重要的改动，越要把“让它做什么”和“怎么证明做对了”写清楚。
推荐做法
- 把现有组件代码和 CSS 约定作为参考，比描述“好看一点”可靠。
- 把任务拆成“输入材料、处理步骤、产出格式、验收方式”四段写给 AI，减少自由发挥。
- 要求它输出可复制的模板、清单或命令，而不是泛泛解释。
- 把 AI 的产出放回真实项目里验证，保留失败信息继续迭代提示词。
一个可直接借用的片段
请先列出你需要读取的文件，再给修改计划。
每次只改一个职责范围。
输出最后必须包含验证命令和风险点。容易踩坑
- 不要让 AI 同时改太多无关文件，范围越大，复核成本越高。
- 不要把密钥、用户隐私、生产日志原文直接贴进提示词。
- 不要把 AI 的解释当成验证结果，能跑的命令和真实页面才算证据。
检查清单
- 提示词里是否包含目标、上下文、限制和验收方式。
- 是否把 AI 的输出拿到真实环境验证。
- 是否检查过敏感信息和版权风险。
- 是否留下人工复核点，而不是全自动通过。
好的技术文章不只是告诉你“可以这么做”，还要说清楚什么时候不该这么做。AI 实用工程 的很多经验，真正值钱的部分都在这些边界里。