文章摘要
本文提出顶尖大语言模型使用应做减法，无需设计复杂prompt，仅需明确任务内容、投入精力、验证标准三个核心要点，人类只需在关键节点予以引导即可。文中还分享了跨会话项目文档管理、模型精力匹配、规避无效测试等实操经验，相关结论具有时效性。

模型越强，规则越少。Prompt 越写越长、技能越堆越多，模型就一定越好用吗？答案是否定的。过度复杂的规则和 prompt 只会干扰顶尖大语言模型，只需明确三个核心要点即可：要做什么、需要投入多少精力、如何验证结果。人类需要做的，是在最关键的地方给出正确引导。

有业内人士整理了在项目文档管理、精力分配、测试与代码评审、prompt 与技能使用、调研与创意挖掘等方面的经验，供大家参考交流。

文中提到的模型包括 GPT-6 Astra、GPT-6 Astra Pro、GPT-6 Luna、GPT-5.6 Sol、Fable 5.1、Opus 5.5、Gemini 4 Argon，这些模型迭代速度快，很多结论有时效性，可能很快就不再适用。

核心观点：工具使用要做减法，人类要把握关键

最近，某大语言模型工具的负责人分享了一个 demo：让 Opus 5.5 为《Acquired》播客中关于 Home Depot 的那一期制作互动网站。出乎他意料的是，没人关注生成的内容，真正引发关注的反而是他分享的 prompt，人们惊讶于这个 prompt 居然如此简单。

该负责人自己回应道，他很惊讶大家会对他给 Claude 写的 prompt 感到惊讶。他认为，prompt 没有什么秘诀，大多数任务不需要过度约束和规定，只要给模型一个目标，它自己会想办法。在 Sonnet 3.5 时期，prompt 很重要，而现在更重要的是向模型讲清楚三点：你想让它做什么、你希望它花多少精力、它应该怎么验证自己做对了。

我非常认同这样的观点，理解是：工具使用要做减法，模型能力越强，人类需要做的越少。最好不要盲目使用一些热度很高的技能之类的东西，不要为了用而用。普遍而言，很多噱头大于实用性，过度复杂的规则设计和 prompt 会严重干扰顶尖大语言模型。

为什么同样的顶尖模型，在不同人的手里发挥的作用不同？因为模型会犯错、会短视、会片面，需要人类在最关键的部分予以正确引导，这正是人机协作最核心的价值。

回过头再看那位负责人的 prompt，虽然简单，但三件事他都说到了：明确要做什么、说明需要的精力、给出验证方式。

一些评论认为，这里面最重要的是第一和第三点，只要讲清楚要做什么、怎么算做好，智能体就能自己去验证、迭代。还有评论说得很直接：“你想要什么，解释得多烂都没关系，只要你把它解释出来。”

后面的内容基本也是围绕这三件事展开：先说清楚要做什么（项目文档管理），再决定花多少力气（精力选择），最后是怎么验证（测试和代码评审）。

Vibe Coding 项目管理浅见

跨会话协作的关键在于文档

大语言模型的上下文窗口是有限的：Codex 默认只支持 258k，可调到 1M，但官方不放心设为默认；Claude Code 默认为 1M；Gemini 4 Argon 支持 2M。不管是 258k 还是 1M，对大项目而言都不够，而且当上下文用到 50% 以上、甚至 70%-80% 时，丢三落四、犯错是不可避免的，因此让智能体在多个会话之间协作是至关重要的。

跨会话协作的关键在于做好项目文档维护和管理。我的习惯是，在一个工作目录下开启与智能体的对话，正式开始之前，先初始化 AGENTS.md，以及下面这些文件夹：

my-project/
├─ AGENTS.md    # 最最最核心！
├─ docs/        # 核心，存放长期维护的文档
│  ├─ README.md # docs/ 的索引，简单的说明
│  ├─ HANDOFF.md# 跨对话长期项目的核心
│  ├─ DATASET.md# 数据集说明
│  └─ ENV.md    # 环境说明
├─ data/        # 数据集放数据盘，这里建软链接
├─ experiments/ # 实验结果，占空间的话也建软链接
├─ notes/       # 草稿、待定决策、头脑风暴、调研
├─ ref-papers/  # 参考文献的 LaTeX source
├─ ref-repos/   # 代码实现的参考
└─ workspace/    # 真正的开发目录

ref-papers/里最好是去获取 LaTeX 源码，保真度最高，就是给 AI 看的。其中最主要的就是 docs/，放的都是长期维护的文档。

在这些文件里，你可以没有其他的，但不能没有 AGENTS.md！

原则：强烈建议人机协作地创建和维护这些文档！当一个错误或问题连续被智能体犯时，就应该把相关说明加到 AGENTS.md 里。

附：我的 AGENTS.md（节选）

# Agents Guidelines
本目录用于 [研究方向] 研究（项目名 [xxx]）：[一句话说明目标]。接手先读 docs/HANDOFF.md；当前主线草案见 notes/cur_mainline.md。

目录与归属


    

  • ref-papers/：参考论文，只读。论文事实以本地原文为准，不凭记忆转述。
    • 

  • workspace/：代码与实验。上游仓库克隆只用于跑基线，改动保持最小；自己的新代码放独立目录；临时文件放 workspace/tmp/<任务名>/。
    • 

  • notes/：调研、讨论、未定稿草案。当前有效草案用 cur_ 前缀，过期后移入 notes/archive/。
    • 

  • docs/：正式文档。HANDOFF.md 为接手入口，ENV.md 为环境，spec/ 为正式方案。
    • 

  • experiments/<name>/：results.md 首屏维护 Current Summary，运行记录写 runs.md。
    • 



环境与执行


    

  • 安装、启动、评测、环境排障先查 docs/ENV.md。
    • 

  • 不要停止非本任务启动的进程。
    • 

  • 长时程任务确认正常运行后，报告任务标识和日志路径，然后停止轮询。
    • 

  • 数据传输持续低速或失败时，停止并报告；不反复重试，不自行更换下载源。
    • 



测试


    

  • 默认不写测试：不补单元测试，跑通一次、看一眼输出即可。
    • 

  • 复现已发表工作时，以对上论文报告的指标为准。
    • 

  • 只有改动自己方法的核心代码（训练流程、数据处理、评分）时才专门验证：先列出可能出错的方式，再用缩小版验证，产出 loss 曲线、指标 JSON 等可核查的结果。
    • 



文档


    

  • 写入前按上面的归属选位置，不新建平行文档。
    • 

  • HANDOFF 只记当前状态、关键决策、已验证结果、接手须知、明确待办；40–70 行量级；修订而非追加。
    • 

  • 原则：删掉某句话不影响接手，就删掉。

关于 Thinking effort 的选择

Codex 别用 Ultra / Max 直接 coding

使用 Codex 时，不要用 Ultra / Max 直接去 coding，特别是 Ultra！Ultra 会生成大量的子代理去辩论，造成无限的挑刺、抬杠，针对大量无意义的边界问题进行测试、打补丁，导致项目臃肿，浪费 token 且腐化上下文。

本质还是 GPT 本身的问题：过度防御性，经常过度谨慎。主代理启用子代理去处理任务，本质是为了减轻主代理的负担、隔离上下文、协作完成任务，但是 GPT 的主代理经常会不信任子代理，简直就是反驳型人格。子代理都跟他说已经完成了，主代理非得再去 double check 一下，这操作既浪费 token 又污染上下文！

Claude Code 的 Ultracode 功能甩 Codex 一万条街！Max 同理。建议将规划与执行解耦：规划可用较高精力，执行用相对低的精力。

注意：这里的解耦和使用不同精力，指的是开多个会话并行处理任务，不是在一个对话中不停切换模型或思考预算。这样会破坏 KV cache（prompt cache），让你的对话更贵、更耗钱。

thinking effort 可以理解为 system prompt 的一部分，切换后之前的 cache 都要丢掉重新计算；切换模型同理。

例外：Claude 最新的模型（Fable 5.1 和 Opus 5.5）已经可以做到改变精力而不破坏 Claude Code 的提示缓存，对话中途也能直接用 /effort 切换（也许后续 Codex 也会跟进，但目前还没有）。

Anthropic 研究员的 370 次实验

你以为 thinking effort 越高模型越聪明？Low 真的要比 High 笨很多吗？实际并不完全是。

Anthropic 研究员 Thariq 用 Fable 5.1 在 Terminal-Bench 3.0 上跑了 370 次，从 low 到 max：

从宏观上讲，effort 让模型能大致了解你希望它为该任务花费多少计算资源。这在某种程度上与你对任务难度的建模有关。

我的理解是，effort 本质就是 prompt，它不会从根本上提高模型的智力水平，只会让模型花更多功夫去想、去验证。

对边界情况多的任务（老代码修 bug、安全、性能优化）很值，但简单的问题过度思考就会过度解读，就像做阅读理解一样。所以 effort 应该与任务难度（以及你想多大程度参与其中）相匹配。

Thariq 的经验法则：

他写新功能的流程（多了一步高精力验证）：

1. 先给 Claude 一份 spec，让它反过来问你，把缺的细节问清楚；

2. 用 low 实现；

3. 自己检查方向对不对，不对就继续用 low 改；

4. 最后切 high 做验证和测试。

烦人的单元测试 & 停不下来的 code review

目前 SOTA 的 LLM 莫名其妙地喜欢各种测试（从 GPT-5.6 Sol 开始！真不知道哪学来的坏毛病），它可能写几千行的代码来做一些根本没意义的测试，这只会导致代码极度臃肿并浪费大量 token。这是社区的共识性问题。

OpenAI 的官方文档其实也解释了一部分原因：以前的模型需要督促才会去跑测试，而 GPT-6 Astra 自己就会做，如果 AGENTS.md 或 prompt 里还留着“记得跑测试”之类的旧指令，就会导致大量不必要的测试。

所以可以先回头检查一下自己的 AGENTS.md 里有没有这类旧指令（但是实际你就算不写，他也会大量写测试）。

一位开发者放在 AGENTS.md 最顶部的三条：

1. 永远不要在写完代码之后再补单元测试。

2. 强烈倾向于把端到端（E2E）测试作为唯一的测试手段；E2E测试结束时，要产出一个可验证、可复现的产物（artifact）。

3. 如果确实需要单独测试某个模块，先把它所有可能出错的方式写下来，再写代码。

我的理解是，LLM 喜欢静态单元测试，写一部分就测一部分，而不是测整个系统，这对 research 而言很多时候毫无帮助，端到端的测试可能更适合我们的场景。

我自己的写法见前面 AGENTS.md 的节选内容

以上内容不代表本平台立场，仅供读者参考