/~learn/s/ef6f9e6f
> 在上一篇 上下文密度衰减 中，我们解释了"为什么精确PRD反而做不好"。这一篇直接给方法论：怎么跟模型说话，才能把它的能力用到极致。
---
传统编程里，你告诉计算机"怎么做"，它精确执行。但 LLM 不是编译器，它是一个读过海量代码、理解设计意图、但注意力带宽有限的聪明实习生。
跟这种人协作的正确方式不是：
"新建一个div，margin-top:16px，padding:12px 16px，里面放一个h2字体大小18px font-weight:600，
下面跟一个p行高1.6颜色#666，右边有个按钮圆角8px hover时scale(1.02) transition 0.2s..."而是：
"做一个简洁现代的卡片组件，标题+描述+右侧操作按钮，风格参考Linear/Notion，
做完跑起来我看看效果。"第二种方式模型能调用它见过的成千上万张优秀卡片设计，做出的东西大概率比你手写30个参数更好看、更协调。
---
Vibe Coding 不是"随便说两句"，而是有方法论的。
| 不说（参数式） | 而说（意图式） |
| -------------- | -------------- |
| 按钮颜色 #007AFF，圆角 8px | 主按钮要显眼但不刺眼，类似 Stripe 的蓝色 |
| 列表间距 16px，分割线 #eee | 列表要呼吸感好，看着不累，像 iOS 设置页 |
| 动画时长 200ms，ease-in-out | 动画要干脆，不拖泥带水，像原生 App |
| 这页要做登录、注册、忘记密码、第三方登录 | 先做最简单的登录页，能跑起来就行 |
原则：凡是能用一个品牌/产品/风格做参照物的，就不要手动描述参数。模型的训练数据里包含了这些产品的 UI 截图描述，它知道"Notion 风"、"Linear 风"、"Apple 风"是什么意思——比你精确到 2dp 靠谱得多。
❌ 错误：一次性要求完整系统
"帮我做一个完整的记账App，要有首页报表、账户管理、分类统计、预算功能、多币种支持..."
✅ 正确：从骨架开始，每次只加一层
第一次："做个最简单的记账页面，能输入金额、选分类、记一笔。"
第二次："现在加个历史列表，能看到今天记的账。"
第三次："加个简单的月度汇总卡片，显示这个月花了多少。"
第四次："首页加个饼图展示分类占比。"每一步都是新的对话、新的上下文，避免"上下文密度衰减"。模型每次只需要关注一个增量任务，成功率暴增。
❌ 错误：没看到东西就调参数
"按钮颜色要 #0066CC，大一点，圆角12px..."
（模型还没写出来，你就在调整幻想中的东西）
✅ 正确：先跑，看，再改
"先做出来让我看看。"
→ 模型给你一版
→ "按钮颜色有点暗，调亮一点，圆角加一点"
→ 模型改
→ "列表间距有点挤，松一点"
→ 模型改人有极强的视觉反馈能力，但模型没有——你让它"脑补"UI，它只能猜；你让它做出来你看，你一秒就能判断好坏。反馈循环是王道。
---
前面说的都是"Vibe Coding 场景"。但工作中很多任务确实需要精确——比如 API 接口必须返回指定字段、算法逻辑必须符合业务规则、数据库 schema 必须满足约束。
这种场景不能简单说"做个XXX"，但也绝不能一次性把所有约束堆进去。正确做法是分治投喂。
Step 1: 先讲清楚"是什么、为什么"（上下文 ≤ 500字）
背景、目标、边界。不涉及具体实现。
Step 2: 让模型给出设计/方案，你来审核
不要直接让它写代码。先让它说"我打算怎么做"，你对方案点头后再进入下一步。
这一步是为了确保它"真的理解了"，不是在瞎猜。
Step 3: 按模块/粒度拆成独立任务，每次只给一个
每个任务独立成段/独立对话，上下文干净。
比如：先写数据模型 → 再写数据库操作 → 再写API层 → 再写前端调用。
Step 4: 写完立即跑/测，看到结果再进下一个
不要让它"一气呵成"写5个文件。每个小模块写完就验证，错了当场改，
不要等5个文件都写完再发现方向错了。
不是所有约束都应该一次说完。把约束分层：
第一层（架构级，一开始说）：
- 用什么技术栈（FastAPI + SQLite + React）
- 数据模型核心字段
- API 的输入输出格式
第二层（实现级，写那个模块前才说）：
- 具体的校验规则
- 错误处理方式
- 分页/排序逻辑
第三层（细节级，看到初版后说）：
- 错误提示文案
- 参数命名调整
- 返回字段补一个第一层一开始说，第二层在写到那个模块时才说，第三层在看到东西之后说。这符合"近端高保真"的注意力分布——你越晚提的约束，模型越记得牢。所以越容易忘的细节，越要在最后时刻才说。
❌ 错误：开头塞30条要求
"要求1.xxx 2.xxx 3.xxx ... 30.xxx，现在开始写代码"
（模型记住前5条+后5条，中间20条看运气）
✅ 正确：写完让它自检
（模型写完代码后）
"现在对照以下清单自检一遍，逐条核对哪里没做到，然后修复：
- [ ] 金额字段用 Decimal 不用 float
- [ ] 所有接口返回统一的 {code, data, msg} 格式
- [ ] 创建时间和更新时间自动维护
- [ ] ..."这利用了两个原理：
---
长对话到一定程度（经验上 20-30 轮之后），模型开始"失忆"和"漂移"：
信号：你发现自己开始反复说"我之前说过XXX"的时候，就是上下文该重置了。
做法：
Trae 里的 .trae/rules/ 和 .claude/CLAUDE.md 就是专门干这个的：
❌ 差：一句话塞三个不相关任务
"顺便帮我把那个bug修了，再加个导出功能，还有首页加个搜索框"
✅ 好：一次只聚焦一件事
"先帮我修这个bug。"
（修完验证完）
"现在加个导出功能。"
（加完验证完）
"首页加个搜索框。"---
不是所有任务都适合交给 LLM，硬塞只会两败俱伤。用下面这张表判断：
| 任务类型 | 模型擅长度 | 正确用法 |
| --------- | ---------- | --------- |
| 从零搭一个新项目/MVP | ★★★★★ | 一句话描述，让它自由发挥 |
| 写工具脚本/数据处理 | ★★★★★ | 讲清输入输出，让它写 |
| 解释/重构/翻译代码 | ★★★★★ | 贴代码+说意图，让它改 |
| Bug 修复（有明确错误信息） | ★★★★☆ | 贴报错+相关代码，让它分析根因 |
| 实现复杂业务逻辑 | ★★★☆☆ | 必须分治投喂，TDD 验证 |
| 精确 UI 还原（像素级） | ★★☆☆☆ | 做初版，你肉眼微调，不要让它猜 |
| 大规模架构设计 | ★★☆☆☆ | 它可以给建议，但决策必须你定 |
| 需要数学/形式证明的逻辑 | ★☆☆☆☆ | 模型会"看起来对"的幻觉，必须手动验证 |
| 多文件协调的大重构 | ★☆☆☆☆ | 拆成多个小重构，每次只动一个模块 |
关键认知：模型不是万能的，但它万能的那部分——生成、补全、探索、翻译、解释——是碾压级别的。把力气花在它擅长的地方，在它不擅长的地方保持人工掌控。
---
你已经从 行为心理学-降低工作摩擦成本 里知道"延迟时间 → 0"是核心。用模型时同样：
反馈速度公式：
模型使用效果 = 模型能力 × 每小时反馈循环次数
一个 GPT-3.5 级别的模型，如果你 30 秒就能看到结果、立刻调整，
效果会远超 GPT-4 但你 10 分钟才能跑一次看结果。具体操作：
---
传统编程思维：想清楚 → 写清楚 → 执行正确
LLM 编程思维：给方向 → 看结果 → 小步调整 → 收敛后者非常像"和人协作"或者"做设计"——你不会对设计师说"这个按钮 8px 圆角、#007AFF 颜色、hover 变深10%"，你会说"感觉不对，不够突出，再试试"。设计师比你更懂设计参数；模型比你更懂"什么样的代码/UI是好的"——只要你给它发挥空间。
最有效的使用方式不是"精确指挥模型做每一步"，而是"告诉它方向，给它参考，让它跑，你看，然后微调"。 这就是为什么 Vibe Coding 反直觉地胜出：它尊重了模型真正的能力结构，而不是把它硬套进传统编程的模子里。
---
---