我每天都要在大模型前面泡上六七个小时文本、代码、表格、整页的文档来来回回差不多能聊上百轮。用得越久越发现一件让人沮丧的事模型本身的智商一直在涨但我自己的“交互方式”却长期停在一个很初级的水平——想到哪问到哪开了新会话就忘掉旧约束模型给出一个听起来很顺滑但完全是自作主张的答案我也经常要到很晚才发现。这个问题的本质不是模型不行而是我没有一套“稳定输出自己真实意图”的方法。后来我把这套方法整理成一份文档化的约定名字就叫《我与大模型的人机交互协议》版本号已经维护到 V2.00。这篇不聊某个具体模型的能力测评只讲清楚这套协议到底是怎么设计的、实际怎么用、以及哪些坑是只有踩过以后才会真正重视的。1. 为什么需要一份“交互协议”三次翻车教会我的事1.1 第一次翻车模型把“帮我改代码”理解成“帮我出方案”那次我让模型帮忙重构一段调度逻辑原话大概是“这段代码有点乱帮我整理一下”。结果它不但把函数内部重写了还顺手改了函数签名、加了一堆异常处理和日志埋点。功能看起来更强壮了但调用方全部对不上一编译全是错。我当时的第一反应是“模型理解能力差”但事后复盘问题出在我自己身上我既没有告诉它“只动函数体不改签名”也没有声明“不要增加新的外部依赖”更没有给出验收标准——什么叫整理好是保持行为不变的前提下优化可读性还是允许调整对外接口我什么都没写模型当然只能按照它自己脑海里的“最佳实践”脑补。这个场景后来成为我设计协议时最重要的反面案例任务边界必须显式声明而且要在执行前声明。1.2 第二次翻车长对话里约束会被“稀释”还有一次我在同一个会话里连续讨论一个项目的多个模块。刚开始我说得很清楚“某个模块的权限校验不能动后续所有改动都要以现有逻辑为基线”。前面两轮模型还遵守得很好到了第五轮它开始给出会绕过现有权限校验的重构建议。我回头翻聊天记录才意识到它并没有“遗忘”而是在长上下文中最初那条约束被后来大量新鲜内容挤到了注意力之外模型在概率上越来越倾向于跟随最近的信息。这就是“上下文稀释”。这次教训让我彻底放弃了把单个会话当成“无限记忆仓库”的想法。每次任务都需要一层明确的环境锚点不能指望模型自己记得你最开头那句轻描淡写的背景。它们的工作方式更像一个阅读速度极快、但页码经常翻乱的同事。1.3 第三次翻车同一个问题三个会话给出三个答案有一段时间我很喜欢攒“万能提示词”。同一个问题我复制到三个新会话里得到的三份答案在结构和结论上差得很远。有的推荐方案A有的推荐方案B还有一份把A和B各自支持者的理由都列了一遍最后说“取决于业务场景”。这不是模型的随机性有多可怕而是因为“同一个问题”背后我的角色、交付格式、上下文、验收标准全都没固定它只能随机选择一种旁路来理解。那一次之后我开始给交互“加约束”而不是给“提示词美容”。也就是从“说一句好听的话”转向“写一份可以被审计的任务书”。效果很快就不一样了。1.4 把“咒语”换成“契约”总结前面三段惨痛经历我的核心转变是把模型从“一个什么都知道的智者”降级为“一个智商很高但极度需要明确指令的新同事”。提示词是一次性的咒语念完就没了结果只能碰运气而契约是可维护的约定它包含边界、角色、格式、验收标准所有偏差都能被事后复盘。V2.00 的整个设计就是围绕“契约化协作”展开的而不是追求某一种更高级的提问句式。提示如果你发现自己正在收藏越来越多的“提示词模板”不妨停下来想想——你缺的不是更好的句子而是一套能让这些句子稳定起作用的执行框架。2. V2.00 协议的整体架构2.1 五件套契约C / T / R / F / VV2.00 把所有交互压缩成五个要件我习惯管它叫“五件套契约”要件含义它解决的核心问题CContext上下文锚点模型不知道该用什么视角理解这个任务TTask任务意图目标不明确模型只能让步过多RRole角色边界模型无法选择立场和判断口径FFormat交付格式输出乱、结构烂、难以直接使用VVerify验收标准完成后无法判定对错只能凭感觉别看这五个单词都很简单真正执行起来绝大多数交互场景都败在前两项。很多人觉得给一串背景就够了其实 Context 的关键不是“多”而是“稳定且可复用”Task 的关键也不是“描述做了什么”而是“说清楚不做什么”。我用一句话来记忆这套契约“不要让模型在‘没有上下文、没有边界、没有格式、没有验收标准’的情况下替你拍板。”五件套里面每一项都对应一个“替模型扫清不确定性”的动作。2.2 协议不是单次动作而是一条状态机现在很多教程会告诉你“写提示词要包含角色任务格式”这没错但那是“一次动作”。实际项目里同一个目标往往要经历多轮对话中间还会有调整。V2.00 把整个协作过程定义成一条清晰的状态机初始化 → 契约确认 → 拆解对齐 → 执行交付 → 校验回溯 →不通过就回到拆解→ 归档复盘初始化建立工作区、写入全局上下文。契约确认模型复述任务确认边界、格式、验收标准。拆解对齐大任务拆成小步骤按顺序执行。执行交付生成内容或代码。校验回溯按验收标准逐条检查不合格就回到拆解阶段重新对齐。归档复盘把这次的任务声明、输出、校验记录保存形成下一次的上下文资产。之所以把它称为“状态机”而不是“聊天流程”是因为模型的每一次输出都会改变状态而状态又必须被显式接住。如果你不管理状态模型就会帮你管理——而它管理的方式往往是“看你最近说的那句”把你带到沟里去。2.3 两个核心抽象上下文块与任务声明整个协议反复在用的就两个抽象概念。第一个是“上下文块”一段可以独立复用、版本化保存的小型信息例如“项目不允许引入新的第三方库”“当前系统用到的认证方式是令牌不是会话”“所有输出文档必须包含目录和修订记录”。上下文块不需要很长关键是高频、强约束、可以被多个任务反复引用。第二个是“任务声明”一份围绕CTRFV写成的结构化工单。它相当于把一次对话的目标、边界、交付物、验收条件提前固化下来。任务声明和聊天记录最大的区别是聊天记录是一次性的、流动的、不可审计的任务声明是可版本化、可追溯、可复用的。这两个抽象组合起来就形成了一个很干净的工作流上下文块提供“静态记忆”任务声明提供“动态指令”模型每次拿到的是两者的组合而不是一段漫无边际的闲聊。3. 协议的具体实现与模板3.1 先搭一个最小工作区我个人的习惯是在电脑里维护一个叫agent-workspace的目录所有涉及模型的协作都会落在这里。目录结构大概是agent-workspace/ ctx/ # 上下文块 base.md # 模型需要知道的通用背景 project.md # 当前项目的技术背景 constraints.md # 硬性约束清单 glossary.md # 术语表 tasks/ # 任务声明 2026-proj-a-001.md outputs/ # 模型输出 logs/ # 交互备忘 templates/ task.md # 任务声明模板 verify.md # 校验清单模板听起来很重但实际跑起来非常轻。最重要就两个文件ctx/constraints.md和任务声明文件。没有它们之前我的交互是“开一个窗口直接问”有它们之后我的交互是“先花三分钟翻一下上下文再开窗口”。3.2 上下文文件怎么写很多人的第一个误区是背景信息越详细越好。我实测不是。上下文文件如果写太长模型的注意力反而会被无关信息干扰重要约束沉在下面根本起不到作用。我的base.md一般写这几个部分# 基础背景 - 协作定位我是项目负责人模型是方案顾问与代码助手。 - 沟通风格优先给结论其次给理由最后给可选方案。 - 默认约定不确定的内容必须明确标注“不确定”不要替我编造。constraints.md则是硬约束每条都是不可妥协的# 硬性约束 - 不引入任何新的第三方依赖除非任务声明中明确允许。 - 不修改对外接口签名除非任务声明中明确要求。 - 所有远程调用必须考虑超时与重试策略不能只写主流程。 - 输出中出现的所有名词须能在项目上下文中找到出处否则标注为“推测”。这里有一个非常关键的原则上下文块在任务执行过程中是“不可动摇的基线”。如果某条约束被放宽应该显式修改上下文块并升级版本号而不是在聊天里说一句“这次可以适当引入新工具”。否则模型很容易在长对话后面忘记这次例外。3.3 任务声明模板每次正式开工前我会复制templates/task.md成一份新的任务文件。模板长这样# 任务声明 ## 契约头 - 任务编号T-2026-001 - 关联上下文ctx/base.md, ctx/project.md, ctx/constraints.md - 任务类型代码审查 / 技术方案 / 内容撰写 / 数据分析 ## C 上下文要点 - 这个任务涉及的系统订单状态机模块 - 已知约束见 ctx/constraints.md 第 1、3 条 - 需要模型特别注意的背景 ## T 任务意图 - 目标一句话 - 非目标明确不做的事 - 成功标准可观察的结果 ## R 角色边界 - 你扮演资深软件架构师 - 你的视角 - 禁止跨越的边界不负责决策只提供分析与建议 ## F 交付格式 - 交付物类型 - 结构要求 - 禁止的格式 ## V 验收标准 - 是否覆盖了全部目标 - 是否不涉及非目标 - 所有关键判断是否在上下文中可追溯 - 存在不确定处是否显式标注第一次填这份文件大概要花十五分钟但填完以后整个交互会变得异常稳定。它不是限制模型的自由而是把模型从“猜你要什么”里解放出来让它的能力全部用在真正的分析上。3.4 校验清单把“我觉得不错”变成“逐条可查”V2.00 里我几乎没有凭感觉验收过输出而是用verify.md做检查。核心就三类事实类输出中哪些断言需要出处这些出处是否真实存在如果模型引用了某个接口或某个概念在项目里搜不到就视为存疑。边界类它有没有做了任务声明里“非目标”部分的内容有没有擅自扩大范围一致性类术语是否统一角色立场是否保持和上下文块的约束是否冲突这份清单本质上就是给模型输出做“代码审查”。模型生成的不是只有代码哪怕是写一段文案我也会按一致性来查——用语有没有漂移人设有没有崩关键结论有没有前后打架。4. 一次完整流程的实操演示4.1 场景设定为了让你直观感受这套协议怎么跑我拿一个很典型的场景来演示某项目里有一份订单状态机模块状态转换多、并发更新频繁。我需要模型帮忙做一次代码审查重点排查并发更新时的状态错乱风险。按照旧习惯我大概会直接贴代码然后问“帮我看下这里有没有问题”。V2.00 的做法完全不同。4.2 初始化工作区与任务声明先花几分钟把上下文块整理好。project.md里写清楚系统是微服务架构、订单状态机用数据库行锁控制并发、所有状态变更要写审计日志。constraints.md里补一条“不要建议引入分布式锁本次只分析现有机制的风险”。然后生成任务声明文件tasks/2026-001.md核心字段如下## T 任务意图 - 目标审查订单状态机模块在并发场景下的状态错乱风险并给出最小改动建议。 - 非目标不重新设计状态机不引入分布式锁与消息队列。 - 成功标准列出至少 3 个具体风险点每个风险点都必须对应到代码中的具体位置。 ## R 角色边界 - 你扮演熟悉订单系统的资深后端开发。 - 你的视角以代码逻辑为依据不进行泛泛而谈。 ## F 交付格式 - 交付物一份 Markdown 审查报告。 - 结构风险清单 → 每个风险的行为链路 → 最小改动建议 → 风险等级。 ## V 验收标准 - 每个风险能否定位到具体函数和调用路径 - 建议是否只基于现有依赖一切就绪后我才把代码和相关上下文一起提供给模型。因为任务声明写得很清楚模型第一轮给出的回复已经比旧方式靠谱得多但校验仍然发现问题。4.3 校验过程中抓到的“自由发挥”我把模型第一轮输出拿出来逐条对照验收标准发现两处问题。第一处它在风险清单里写了一条“建议引入数据库层乐观锁配合版本号字段”。这句话看起来没问题但如果严格按照任务声明本次非目标是“只分析现有机制风险不引入新的并发控制工具”。乐观锁不是分布式锁但确实属于“新的并发控制方案”属于扩大范围。第二处它引用了一个我项目里根本不存在的接口名说该接口会在状态流转时被调用我搜索整个仓库都没有找到。这属于典型的“上下文外推断”。我没有直接返工而是补了一条新的上下文约束“所有引用的函数和接口必须能在仓库中搜索到如果属于推测请标注”然后让模型重新生成。这个动作就是前面状态机里的“校验回溯”。4.4 第二轮输出与归档第二轮输出的质量明显上了一个台阶它把三个风险点全部定位到了具体方法给出的最小改动建议确实只依赖现有组件那个不存在的接口也被替换成对真实逻辑的分析并主动标注“基于现有代码判断可能存在其他调用路径需要人工确认”。到这里任务才算验收通过。之后我再把这次的task.md、模型输出和校验记录一起存档。下次再聊这个模块它们就变成了新的上下文块的一部分。这套流程跑顺之后我的交互成本其实没有增加被动返工反而少了一大截。5. 高频翻车现场与排查手册这几年来我自己和身边同事用得最多的排查表就是下面这张“症状与处置对照表”。症状常见原因协议处置模型自作主张增加功能或约束任务里“非目标”缺失在 T 中显式写明“不做什么”长对话后半段跑题约束被新信息稀释重新注入上下文块必要时新建会话同一问题多会话答案不一致上下文、角色、格式未固定统一走任务声明不靠口头描述输出内容看起来很对但没有出处模型在补全默认假设验收集里强制“可追溯性”输出的格式杂乱没法用交付格式写得模糊在 F 里给出具体结构示例5.1 模型“把任务改写成自己的方向”这是最常见的一类核心原因就是我在第一章里说的“边界缺失”。处置办法不是加一句礼貌用语而是要在任务声明里给出“否决区”明确写出哪些做法本次不用比如“不要考虑用分布式缓存”“不要重写日志框架”“不需要兼容移动端”。模型在绝大多数情况下会尊重这些显式的否定约束前提是你自己记得把它们写下来。5.2 模型“真的忘了上下文”很多人以为关掉再开一个会话就是重来其实模型每次对话都是“从零开始”它的记忆只在当次会话中有效。所以我现在的习惯是一旦发现约束开始不稳就立刻回到工作区把上下文块和任务声明重新喂一遍。尤其是当会话超过五六轮以后我会主动在内容里加一句“以上约束仍然全部有效请基于它们继续”。5.3 模型“一本正经地编造”一开始我以为这是模型故意在“骗我”后来想明白了它只是基于概率生成最流畅的文本在信息缺失的位置会自动补一个“合理但不一定存在”的内容。这一点要靠校验清单去防而不能指望模型自己承认。最简单的方式就是在 V 里加一条“所有无法验证的内容都必须显式标注为推测”这比事后发现幻觉再满头大汗地返工要省力得多。5.4 格式类翻车很多时候模型给的不是“错”是“没法直接用”。比如让它写周报它写了一整段散文让它给配置它把说明文字和配置内容混在一起。处理方式是在 F 中直接给出一个结构示例模型会非常忠诚地模仿那个结构。给出的示例越具体输出越不容易乱。这条我实测下来是性价比最高的一个调整。6. 一点经验与协议的后续扩展踩过这么多坑以后我最大的体会是协议表面上是约束模型的实际上约束的是我自己。模型并不会因为你有了一套漂亮文件就变聪明但你会发现自己的问题边界变清晰了、验收习惯变好了、返工变少了。说句直白的话模型的上限由算法决定但我与人机协作的上限由“我愿不愿意把话说清楚”决定。这套协议目前还在继续迭代。我最近在做三件事一是把task.md模板脚本化用一个简单的命令行工具来生成任务文件、自动注入上下文块让协议流程再快一点二是把历史任务记录整理成“可复用经验库”让模型在参与新任务时能参考以前踩过坑的结论三是尝试把协议文档本身作为一个上下文块交给模型让模型来帮我校对协议里有没有自相矛盾的地方这有点像让代码去审查编译器。最后分享一个我一直保留的小技巧每次正式发起一个任务之前先用自己的话把“目标一句话、不要做什么、交付格式是什么”复述一遍。如果你在三十秒内说不清楚这三件事那模型替你拍板的概率就非常大了。这套 V2.00 协议本质上就是给“说不清楚”这件事兜底的一层脚手架希望它对你也有用。
我每天都要在大模型前面泡上六七个小时文本、代码、表格、整页的文档来来回回差不多能聊上百轮。用得越久越发现一件让人沮丧的事模型本身的智商一直在涨但我自己的“交互方式”却长期停在一个很初级的水平——想到哪问到哪开了新会话就忘掉旧约束模型给出一个听起来很顺滑但完全是自作主张的答案我也经常要到很晚才发现。这个问题的本质不是模型不行而是我没有一套“稳定输出自己真实意图”的方法。后来我把这套方法整理成一份文档化的约定名字就叫《我与大模型的人机交互协议》版本号已经维护到 V2.00。这篇不聊某个具体模型的能力测评只讲清楚这套协议到底是怎么设计的、实际怎么用、以及哪些坑是只有踩过以后才会真正重视的。1. 为什么需要一份“交互协议”三次翻车教会我的事1.1 第一次翻车模型把“帮我改代码”理解成“帮我出方案”那次我让模型帮忙重构一段调度逻辑原话大概是“这段代码有点乱帮我整理一下”。结果它不但把函数内部重写了还顺手改了函数签名、加了一堆异常处理和日志埋点。功能看起来更强壮了但调用方全部对不上一编译全是错。我当时的第一反应是“模型理解能力差”但事后复盘问题出在我自己身上我既没有告诉它“只动函数体不改签名”也没有声明“不要增加新的外部依赖”更没有给出验收标准——什么叫整理好是保持行为不变的前提下优化可读性还是允许调整对外接口我什么都没写模型当然只能按照它自己脑海里的“最佳实践”脑补。这个场景后来成为我设计协议时最重要的反面案例任务边界必须显式声明而且要在执行前声明。1.2 第二次翻车长对话里约束会被“稀释”还有一次我在同一个会话里连续讨论一个项目的多个模块。刚开始我说得很清楚“某个模块的权限校验不能动后续所有改动都要以现有逻辑为基线”。前面两轮模型还遵守得很好到了第五轮它开始给出会绕过现有权限校验的重构建议。我回头翻聊天记录才意识到它并没有“遗忘”而是在长上下文中最初那条约束被后来大量新鲜内容挤到了注意力之外模型在概率上越来越倾向于跟随最近的信息。这就是“上下文稀释”。这次教训让我彻底放弃了把单个会话当成“无限记忆仓库”的想法。每次任务都需要一层明确的环境锚点不能指望模型自己记得你最开头那句轻描淡写的背景。它们的工作方式更像一个阅读速度极快、但页码经常翻乱的同事。1.3 第三次翻车同一个问题三个会话给出三个答案有一段时间我很喜欢攒“万能提示词”。同一个问题我复制到三个新会话里得到的三份答案在结构和结论上差得很远。有的推荐方案A有的推荐方案B还有一份把A和B各自支持者的理由都列了一遍最后说“取决于业务场景”。这不是模型的随机性有多可怕而是因为“同一个问题”背后我的角色、交付格式、上下文、验收标准全都没固定它只能随机选择一种旁路来理解。那一次之后我开始给交互“加约束”而不是给“提示词美容”。也就是从“说一句好听的话”转向“写一份可以被审计的任务书”。效果很快就不一样了。1.4 把“咒语”换成“契约”总结前面三段惨痛经历我的核心转变是把模型从“一个什么都知道的智者”降级为“一个智商很高但极度需要明确指令的新同事”。提示词是一次性的咒语念完就没了结果只能碰运气而契约是可维护的约定它包含边界、角色、格式、验收标准所有偏差都能被事后复盘。V2.00 的整个设计就是围绕“契约化协作”展开的而不是追求某一种更高级的提问句式。提示如果你发现自己正在收藏越来越多的“提示词模板”不妨停下来想想——你缺的不是更好的句子而是一套能让这些句子稳定起作用的执行框架。2. V2.00 协议的整体架构2.1 五件套契约C / T / R / F / VV2.00 把所有交互压缩成五个要件我习惯管它叫“五件套契约”要件含义它解决的核心问题CContext上下文锚点模型不知道该用什么视角理解这个任务TTask任务意图目标不明确模型只能让步过多RRole角色边界模型无法选择立场和判断口径FFormat交付格式输出乱、结构烂、难以直接使用VVerify验收标准完成后无法判定对错只能凭感觉别看这五个单词都很简单真正执行起来绝大多数交互场景都败在前两项。很多人觉得给一串背景就够了其实 Context 的关键不是“多”而是“稳定且可复用”Task 的关键也不是“描述做了什么”而是“说清楚不做什么”。我用一句话来记忆这套契约“不要让模型在‘没有上下文、没有边界、没有格式、没有验收标准’的情况下替你拍板。”五件套里面每一项都对应一个“替模型扫清不确定性”的动作。2.2 协议不是单次动作而是一条状态机现在很多教程会告诉你“写提示词要包含角色任务格式”这没错但那是“一次动作”。实际项目里同一个目标往往要经历多轮对话中间还会有调整。V2.00 把整个协作过程定义成一条清晰的状态机初始化 → 契约确认 → 拆解对齐 → 执行交付 → 校验回溯 →不通过就回到拆解→ 归档复盘初始化建立工作区、写入全局上下文。契约确认模型复述任务确认边界、格式、验收标准。拆解对齐大任务拆成小步骤按顺序执行。执行交付生成内容或代码。校验回溯按验收标准逐条检查不合格就回到拆解阶段重新对齐。归档复盘把这次的任务声明、输出、校验记录保存形成下一次的上下文资产。之所以把它称为“状态机”而不是“聊天流程”是因为模型的每一次输出都会改变状态而状态又必须被显式接住。如果你不管理状态模型就会帮你管理——而它管理的方式往往是“看你最近说的那句”把你带到沟里去。2.3 两个核心抽象上下文块与任务声明整个协议反复在用的就两个抽象概念。第一个是“上下文块”一段可以独立复用、版本化保存的小型信息例如“项目不允许引入新的第三方库”“当前系统用到的认证方式是令牌不是会话”“所有输出文档必须包含目录和修订记录”。上下文块不需要很长关键是高频、强约束、可以被多个任务反复引用。第二个是“任务声明”一份围绕CTRFV写成的结构化工单。它相当于把一次对话的目标、边界、交付物、验收条件提前固化下来。任务声明和聊天记录最大的区别是聊天记录是一次性的、流动的、不可审计的任务声明是可版本化、可追溯、可复用的。这两个抽象组合起来就形成了一个很干净的工作流上下文块提供“静态记忆”任务声明提供“动态指令”模型每次拿到的是两者的组合而不是一段漫无边际的闲聊。3. 协议的具体实现与模板3.1 先搭一个最小工作区我个人的习惯是在电脑里维护一个叫agent-workspace的目录所有涉及模型的协作都会落在这里。目录结构大概是agent-workspace/ ctx/ # 上下文块 base.md # 模型需要知道的通用背景 project.md # 当前项目的技术背景 constraints.md # 硬性约束清单 glossary.md # 术语表 tasks/ # 任务声明 2026-proj-a-001.md outputs/ # 模型输出 logs/ # 交互备忘 templates/ task.md # 任务声明模板 verify.md # 校验清单模板听起来很重但实际跑起来非常轻。最重要就两个文件ctx/constraints.md和任务声明文件。没有它们之前我的交互是“开一个窗口直接问”有它们之后我的交互是“先花三分钟翻一下上下文再开窗口”。3.2 上下文文件怎么写很多人的第一个误区是背景信息越详细越好。我实测不是。上下文文件如果写太长模型的注意力反而会被无关信息干扰重要约束沉在下面根本起不到作用。我的base.md一般写这几个部分# 基础背景 - 协作定位我是项目负责人模型是方案顾问与代码助手。 - 沟通风格优先给结论其次给理由最后给可选方案。 - 默认约定不确定的内容必须明确标注“不确定”不要替我编造。constraints.md则是硬约束每条都是不可妥协的# 硬性约束 - 不引入任何新的第三方依赖除非任务声明中明确允许。 - 不修改对外接口签名除非任务声明中明确要求。 - 所有远程调用必须考虑超时与重试策略不能只写主流程。 - 输出中出现的所有名词须能在项目上下文中找到出处否则标注为“推测”。这里有一个非常关键的原则上下文块在任务执行过程中是“不可动摇的基线”。如果某条约束被放宽应该显式修改上下文块并升级版本号而不是在聊天里说一句“这次可以适当引入新工具”。否则模型很容易在长对话后面忘记这次例外。3.3 任务声明模板每次正式开工前我会复制templates/task.md成一份新的任务文件。模板长这样# 任务声明 ## 契约头 - 任务编号T-2026-001 - 关联上下文ctx/base.md, ctx/project.md, ctx/constraints.md - 任务类型代码审查 / 技术方案 / 内容撰写 / 数据分析 ## C 上下文要点 - 这个任务涉及的系统订单状态机模块 - 已知约束见 ctx/constraints.md 第 1、3 条 - 需要模型特别注意的背景 ## T 任务意图 - 目标一句话 - 非目标明确不做的事 - 成功标准可观察的结果 ## R 角色边界 - 你扮演资深软件架构师 - 你的视角 - 禁止跨越的边界不负责决策只提供分析与建议 ## F 交付格式 - 交付物类型 - 结构要求 - 禁止的格式 ## V 验收标准 - 是否覆盖了全部目标 - 是否不涉及非目标 - 所有关键判断是否在上下文中可追溯 - 存在不确定处是否显式标注第一次填这份文件大概要花十五分钟但填完以后整个交互会变得异常稳定。它不是限制模型的自由而是把模型从“猜你要什么”里解放出来让它的能力全部用在真正的分析上。3.4 校验清单把“我觉得不错”变成“逐条可查”V2.00 里我几乎没有凭感觉验收过输出而是用verify.md做检查。核心就三类事实类输出中哪些断言需要出处这些出处是否真实存在如果模型引用了某个接口或某个概念在项目里搜不到就视为存疑。边界类它有没有做了任务声明里“非目标”部分的内容有没有擅自扩大范围一致性类术语是否统一角色立场是否保持和上下文块的约束是否冲突这份清单本质上就是给模型输出做“代码审查”。模型生成的不是只有代码哪怕是写一段文案我也会按一致性来查——用语有没有漂移人设有没有崩关键结论有没有前后打架。4. 一次完整流程的实操演示4.1 场景设定为了让你直观感受这套协议怎么跑我拿一个很典型的场景来演示某项目里有一份订单状态机模块状态转换多、并发更新频繁。我需要模型帮忙做一次代码审查重点排查并发更新时的状态错乱风险。按照旧习惯我大概会直接贴代码然后问“帮我看下这里有没有问题”。V2.00 的做法完全不同。4.2 初始化工作区与任务声明先花几分钟把上下文块整理好。project.md里写清楚系统是微服务架构、订单状态机用数据库行锁控制并发、所有状态变更要写审计日志。constraints.md里补一条“不要建议引入分布式锁本次只分析现有机制的风险”。然后生成任务声明文件tasks/2026-001.md核心字段如下## T 任务意图 - 目标审查订单状态机模块在并发场景下的状态错乱风险并给出最小改动建议。 - 非目标不重新设计状态机不引入分布式锁与消息队列。 - 成功标准列出至少 3 个具体风险点每个风险点都必须对应到代码中的具体位置。 ## R 角色边界 - 你扮演熟悉订单系统的资深后端开发。 - 你的视角以代码逻辑为依据不进行泛泛而谈。 ## F 交付格式 - 交付物一份 Markdown 审查报告。 - 结构风险清单 → 每个风险的行为链路 → 最小改动建议 → 风险等级。 ## V 验收标准 - 每个风险能否定位到具体函数和调用路径 - 建议是否只基于现有依赖一切就绪后我才把代码和相关上下文一起提供给模型。因为任务声明写得很清楚模型第一轮给出的回复已经比旧方式靠谱得多但校验仍然发现问题。4.3 校验过程中抓到的“自由发挥”我把模型第一轮输出拿出来逐条对照验收标准发现两处问题。第一处它在风险清单里写了一条“建议引入数据库层乐观锁配合版本号字段”。这句话看起来没问题但如果严格按照任务声明本次非目标是“只分析现有机制风险不引入新的并发控制工具”。乐观锁不是分布式锁但确实属于“新的并发控制方案”属于扩大范围。第二处它引用了一个我项目里根本不存在的接口名说该接口会在状态流转时被调用我搜索整个仓库都没有找到。这属于典型的“上下文外推断”。我没有直接返工而是补了一条新的上下文约束“所有引用的函数和接口必须能在仓库中搜索到如果属于推测请标注”然后让模型重新生成。这个动作就是前面状态机里的“校验回溯”。4.4 第二轮输出与归档第二轮输出的质量明显上了一个台阶它把三个风险点全部定位到了具体方法给出的最小改动建议确实只依赖现有组件那个不存在的接口也被替换成对真实逻辑的分析并主动标注“基于现有代码判断可能存在其他调用路径需要人工确认”。到这里任务才算验收通过。之后我再把这次的task.md、模型输出和校验记录一起存档。下次再聊这个模块它们就变成了新的上下文块的一部分。这套流程跑顺之后我的交互成本其实没有增加被动返工反而少了一大截。5. 高频翻车现场与排查手册这几年来我自己和身边同事用得最多的排查表就是下面这张“症状与处置对照表”。症状常见原因协议处置模型自作主张增加功能或约束任务里“非目标”缺失在 T 中显式写明“不做什么”长对话后半段跑题约束被新信息稀释重新注入上下文块必要时新建会话同一问题多会话答案不一致上下文、角色、格式未固定统一走任务声明不靠口头描述输出内容看起来很对但没有出处模型在补全默认假设验收集里强制“可追溯性”输出的格式杂乱没法用交付格式写得模糊在 F 里给出具体结构示例5.1 模型“把任务改写成自己的方向”这是最常见的一类核心原因就是我在第一章里说的“边界缺失”。处置办法不是加一句礼貌用语而是要在任务声明里给出“否决区”明确写出哪些做法本次不用比如“不要考虑用分布式缓存”“不要重写日志框架”“不需要兼容移动端”。模型在绝大多数情况下会尊重这些显式的否定约束前提是你自己记得把它们写下来。5.2 模型“真的忘了上下文”很多人以为关掉再开一个会话就是重来其实模型每次对话都是“从零开始”它的记忆只在当次会话中有效。所以我现在的习惯是一旦发现约束开始不稳就立刻回到工作区把上下文块和任务声明重新喂一遍。尤其是当会话超过五六轮以后我会主动在内容里加一句“以上约束仍然全部有效请基于它们继续”。5.3 模型“一本正经地编造”一开始我以为这是模型故意在“骗我”后来想明白了它只是基于概率生成最流畅的文本在信息缺失的位置会自动补一个“合理但不一定存在”的内容。这一点要靠校验清单去防而不能指望模型自己承认。最简单的方式就是在 V 里加一条“所有无法验证的内容都必须显式标注为推测”这比事后发现幻觉再满头大汗地返工要省力得多。5.4 格式类翻车很多时候模型给的不是“错”是“没法直接用”。比如让它写周报它写了一整段散文让它给配置它把说明文字和配置内容混在一起。处理方式是在 F 中直接给出一个结构示例模型会非常忠诚地模仿那个结构。给出的示例越具体输出越不容易乱。这条我实测下来是性价比最高的一个调整。6. 一点经验与协议的后续扩展踩过这么多坑以后我最大的体会是协议表面上是约束模型的实际上约束的是我自己。模型并不会因为你有了一套漂亮文件就变聪明但你会发现自己的问题边界变清晰了、验收习惯变好了、返工变少了。说句直白的话模型的上限由算法决定但我与人机协作的上限由“我愿不愿意把话说清楚”决定。这套协议目前还在继续迭代。我最近在做三件事一是把task.md模板脚本化用一个简单的命令行工具来生成任务文件、自动注入上下文块让协议流程再快一点二是把历史任务记录整理成“可复用经验库”让模型在参与新任务时能参考以前踩过坑的结论三是尝试把协议文档本身作为一个上下文块交给模型让模型来帮我校对协议里有没有自相矛盾的地方这有点像让代码去审查编译器。最后分享一个我一直保留的小技巧每次正式发起一个任务之前先用自己的话把“目标一句话、不要做什么、交付格式是什么”复述一遍。如果你在三十秒内说不清楚这三件事那模型替你拍板的概率就非常大了。这套 V2.00 协议本质上就是给“说不清楚”这件事兜底的一层脚手架希望它对你也有用。
