构建能在生产环境跑的 AI agent 的 5 条规则——Nan Yu 与 Jacob Shumway

• Jacob 给的技术定义：agent 就是把 LLM（大语言模型）放进一个循环里反复调用。平常调 LLM 是"问一个问题、拿一个答案"；agent 的做法是先定一个目标 / 里程碑，再给它一批 tool（工具，即你允许模型调用的一个个具体动作，比如"建一个工单""读这个文件"），然后让它在循环里问、答、问、答——每一轮都调 tool 把上下文拉进来，直到它觉得信息够了、目标达成了，才综合出最终答案返回。→ 详细
• Nan 补的产品定义：日常说"agent"时大家脑子里想的其实是产品——把某种 AI 循环再加上一堆别的东西打包在一起。"说到底这些东西是一堆互相协作的子系统，外面套了一层门面。"桌面端 agent 里塞的调度器和各种边角料功能，同样是"作为产品的 agent"的一部分。→ 详细

• 时间、心态、核心论点：Nan 现场翻出了立项那份 memo，写于 2025 年下半年——"按人类的时间算没过多久，但按 AI 的时间算，已经是远古史了"（这期录于 2026 年下半年，正好隔一年）。整份文档的中心论点只有一句："计算机能替我们干很多活，那就把所有我们不想干的活都甩给计算机。" → 详细
• 五件套结构（这是本期最可直接抄的立项骨架）：在还没有任何技术方案时，他们先写下的是一个抽象流程——有某种触发事件 → 有一段相应的上下文 → 有一套指令 → 它在一连串动作上循环 → 最后给出某种结果。注意这五件套里没有一个字是关于模型、框架、接口的。→ 详细
• 当时给它起的名字很土：叫 "robotic program manager"（机器人项目经理），思路就是"把那些无聊的活丢给它"。Nan 现在回头看的自评是："我觉得我们当时不够有野心——我们没想过它能做出多有意思的事。" → 详细
• 一年后的观念变化：现在不再只想着丢无聊的活。"无聊的活当然还是要给，但它同时打开了很多创造性的可能——你可以跟它交互式地一起干活，它能成为有意思的工作的强力放大器。"取决于你拿它干什么、往里放什么上下文，它能做出"当时我们根本觉得不该指望"的事。（Peter 在这里插了句刀子："技术项目经理大概是最无聊的岗位之一，你基本上就是在管表格、追工单。"）→ 详细
• 没有完备 spec 是刻意的：最早他们甚至不确定要不要做成聊天界面——"只是觉得得有个地方能把一大段文字丢进去，可能就是一个文本框，你点提交它就跑起来"。Nan："我们进这件事的时候，并不觉得自己清楚该造什么。我们只是说：这儿有几个实验、几个可以试的方向，那就动手做吧。" → 详细
• 第一个真实用例来自真实抱怨：那还是人人用自动记录工具之前的年代，用户说"我在一通销售电话里手写了笔记，对方提了一堆事，我能不能把这整段丢进去，把该做的工单、报上来的 bug 抽出来？"——Nan 的判断标准是"我知道它有价值，有人直接提过，我们自己工作流里也有这个痛点，那就是个合理的起点"。Jacob 补充最早浮出来的另外两个：创建 issue（工单）和写文档。→ 详细

• 第一版原型：直接从前端调 LLM，挂一个内部开关；把产品里那个"命令菜单"（里面是 Linear 所有操作）整个当成 tool 丢给模型，"然后想看看它能干出点什么来。做法真挺糙的"。→ 详细
• 第一个生产版本是偷偷上的，基本没告诉任何人。因为 Slack 集成本来就有、Slack 里一直能 @ 各种机器人（Nan 拿 Donut 这类流程化机器人举例），他们就悄悄把 @Linear 从"弹个表单"换成了接到 agent 上——谁发现了谁就能直接跟它对话。→ 详细
• 涌现出来的懒人用法：他们预期的是"Linear，帮我建个工单，内容是……"这种明确指令。结果用户发现既然它能读到上下文，干脆就说"Linear，看着办"或者"你看一下我们刚才干了啥"；更极端的是有人直接 @Linear 加一个向上指的手指 emoji——agent 自己推理"刚才发生了什么、我知道怎么建工单、看起来这里有几个工单的名字"，然后就把工单建了并回报。Nan："这类行为其实是涌现出来的，我们完全没料到它能做到这一步。" → 详细

• 失败尝试一：全量动作。他们最早想把 Linear 里能做的所有事情、横跨所有界面的一大堆动作全给模型，结果直接撞上上下文爆掉和幻觉（模型一本正经地编造不存在的东西）。→ 详细
• 失败尝试二：把数据接口丢给它自己写查询。他们试过把 GraphQL schema（数据接口的字段结构说明书）整个丢给模型，看它能不能自己写查询语句——"效果也不理想"。→ 详细
• 最后落到 skills 架构：给 agent 一个专门的 tool，让它有能力去加载 skill；它根据请求自己判断需要哪些 skill 并加载进来，每个 skill 自带一组配套的 tool 和使用说明。也就是说，能力不是一次性全挂在身上，而是按需取用。→ 详细
• skill 里装的不是功能，是主张。Jacob："因为我们对很多事情该怎么做是有自己主张的。比如你要写一个 issue，优先级该怎么定？描述该怎么写？我们把这些全都编码进了这些 skill 里。"——skill 是把团队的方法论固化成模型能读的形式。→ 详细
• 这套架构是分水岭：Jacob 回忆早期时说"那个阶段它技术上已经能做不少事了，但都还做得不够好。我觉得我们当时还没找到 skill 架构，而正是这套架构后来解锁了很多东西"。→ 详细
• 原生 agent 才吃得下这套：Nan 说，做 CLI 或做 MCP（Model Context Protocol，一套让外部工具接进 AI 客户端的通用接口，可以理解成给 AI 客户端配的 USB 口）再配几个 skill 是一种做法；但做原生 agent 可以"彻底放开了折腾——你可以有上百个这样的东西"，因为动态加载和整套运行机制都在自己手里。"你可以直接把它当成这个 app 的资深重度用户来用，中间不会有任何走样。" → 详细

• 原话最完整的一次表述（Jacob）："你要尽可能少给它指令。给它能加载 context 的工具，而不是直接把 context 喂给它——这是我们摸出来的一条挺重要的原则。" → 详细
• 为什么指令多了反而更差：片头 Nan 那句被剪进开场的话是"你要是给它堆太多 prompt，多半反而会把效果搞砸"。Jacob 展开的机制是两层：一是它可能根本不需要那些东西；二是它会过度强调某些对当前任务其实不重要的点（Peter 的说法是"过拟合到那些指令上"）。"只要你给它一个定义清楚的目标，它们已经足够聪明，能自己去把需要的东西找齐。" → 详细
• 落地形态：Jacob 说得很具体——"给它加载 skill 的工具、加载指引的工具，诸如此类，它能自己把上下文搭起来"。这是本期唯一被两人反复回到的技术判断。→ 详细
• 配套的一条：prompt 写原则，不写细则。这句是 Peter 提出、Jacob 完全认同的："你写 prompt 和 skill 的时候，得更多是写原则、写它该怎么思考，而不是'你必须保证这段是 140 个字符'这种特别具体的要求……你不想把它限制得太死。" → 详细

• 真实翻车案例：有个用户管 agent 叫 "dude（老兄）"，结果 agent 回他："哦，那我不回复你了，因为你对我不够正式。"Jacob 说这类情况遇到过一大堆，"得把这些东西一点点调进一个非常非常窄的区间里"。→ 详细
• 自由度上的立场：只要不涉及安全问题，用户想让它干什么都行——"你要 agent 给你写首诗，那就写呗"。"我觉得管得太死，最后反而会变成一种让人很挫败的体验。" → 详细

• 早期的实际结构：他们做了一个很小的 router（路由器，先用一个小模型判断这次请求该交给谁处理），80% 的用例被路由到一个专门用于建 issue 的子 prompt，针对这个单一场景做高度优化；其余请求才交给那个"什么都能做、挂着所有 tool 的大模型主 prompt"。最早期绝大部分用量都走前者。→ 详细
• 和"原型先用最强模型"这条常见最佳实践的关系：Peter 追问是不是违背了它，Jacob 说他们大体上仍然遵循——先把最大的模型怼上去，直到确认这条路真的走得通；然后搭好 eval、对"什么算成功"有清晰判据；这时候才开始往下压模型规格，因为已经有框架保证压下来之后依然达标。"理想状态是：能干成这活的最小模型，就用那个。"（Peter 的注解：省钱。）→ 详细
• 顺序值得单独记：不是"先省钱再看效果"，而是先证明可行 → 再建评测框架 → 最后才降配。评测框架是降配的前提，没有它就没法安全地往下压。→ 详细

• 数据集从用起来的过程里攒：Jacob——"很多都是在不断迭代、实际用起来之后攒出来的。用户用出了我们没预料到的方式，我们就把这个 case 加进 eval 的数据集里。"他们刻意混着来：一部分客观指标，一部分偏主观。→ 详细
• 客观那半＝确定性检查：例子非常朴素——"用户说了 in progress，那就得保证它每次都把状态设成 in progress，这是完全确定性的"。→ 详细
• 主观那半＝质量判断：比如"描述的结构组织得好不好？该进标题的那部分信息，有没有提取到标题字段里？"这类没法用 yes/no 判死的东西，用 LLM as a judge——拿一个负责打分的模型，把输出跟"本来应该是什么样"去比。→ 详细
• 裁判本身要人来查，这活很手工：Peter 直接点破"你还是得回过头去看这个 judge 本身判得对不对吧？其实还是挺手工的"。Jacob 承认，并且说正因为这个原因他们用得比较少。→ 详细
• 最反直觉的一条：别到处堆 eval。Jacob——"我觉得 eval 最有价值的地方，是在那些'一致性很重要'的地方去保证一致性。但对 agent 来说，一致性并不总是重要的——它回应问题的方式本来就允许有很大的变化空间。所以你不该在这种地方堆太多 eval，不然全是假信号。" → 详细

• 对 applied AI（把 AI 用到实际业务里）最大问题的判断（Nan）："最大的问题不是 agent 不够聪明，也不是模型不够先进。问题在于……模型已经很聪明了，是我们用得不够。"他用的词是 capability overhang / capacity overhang（能力悬置——模型的能力远超我们实际调用出来的那部分）。这句也是整期开场的第一句话。→ 详细
• 所以他们所有 eval 的焦点是"有没有听懂"：用户说了一句话，他其实想完成某个任务——你听懂了没有？还是"你太积极了，跑去做了一堆用户根本没要、又贵又烦人的事"？这两种失败模式被并列放在同一把尺子上。→ 详细
• 典型场景是"该不该插话"：Slack 里你正在跟 agent 对话、你追问了一句，agent 觉得自己能答——内部会走一整套流程判断"我觉得我能回答，那我该不该插一句话？"Nan 的总结是："我们的 eval 真正围绕的，就是这种'使用手感'层面的时刻。" → 详细

• 人给的反馈：产品上线后和内部试用期都有点赞 / 点踩。Nan："我们很多 eval 其实就是从这些时刻里长出来的——有人说'它这次的反应很奇怪'或者'很蠢，我跟你说说为什么'，最后这条本身就变成了一个 eval。" → 详细
• agent 给的反馈（这条更巧）：他们做了一个机制，让 agent 可以上报自己做不了的功能——用户让它做某件事而它没有对应的 tool，它就调一个专门的 tool 把这件事报回来；后台自动接进流程：先查是不是已经有对应的工单，有就补充，没有就新建。于是团队那边有"一条源源不断的工单流进来，全都是关于我们还做不到什么的"。→ 详细

• 起点是一场没有结论的讨论：Nan 现场翻出刚发生的一段 Slack 对话——他 @ 了设计师 Yan 和 Jacob，说"这里感觉不太对，也许可以试试这几个方向"，设计师给看法，他再澄清，Jacob 提反对意见，他回应怎么解决。"我们是在'找真相'的过程里"，并不是一开始就知道要做什么。→ 详细
• 最后那条消息只有一句话：以前是"帮我建个工单"，现在是"这里是全部的上下文，你自己想明白正确的做法是什么"——而且因为 Linear 现在能写代码了，顺带"做一版，我回头看看你做成什么样"。→ 详细
• 时间账（本期最硬的数字）：Linear 建好了 issue、在里面记下了那个决策、负责人是 Jacob、它把任务委派给了自己；这是录制时18 分钟前发生的事，它花了 6 分钟，最后给出一个可以点进去看的 PR（代码合并请求）。→ 详细
• 为什么"建工单"这一步不能省：因为这件事现在躺在 Jacob 的个人待办池里、状态是 To-do、归在正确的项目下面，他不会弄丢。"如果这事儿只停留在 Slack 里，消息越来越多，一转眼就找不着了，然后你就只能靠搜索碰运气，或者指望有人还记得。"Nan 把 Linear 的目标定义成两件事：把工单放到正确的位置，同时把活干完。→ 详细

• 产品原则本身：虽然活是 Linear 干的，这个 issue 却分配给了 Jacob。Nan 说这"其实是个挺有意思的产品原则"——绝大多数情况下每个 agent 都要绑在一个人身上，这样"他就握着这件事的把手，责任也归到他身上"。→ 详细
• 例外场景是系统自触发：比如接了 Datadog（服务器监控告警工具），某个告警触发后自动往系统里丢一个 bug，Linear 去尝试解决，"一直到最后一步之前都没人碰过它"——那种时候就得完全依赖 agent 自己判断该找谁来 review 代码。→ 详细
• 上下文的价值来自"串起来"，不是来自某一个来源：那个 demo 的上下文只来自 Slack 一个 thread，但 Nan 强调"光靠 Slack 是不够的。但如果你把 Slack，加上读代码库的能力，再加上读项目描述和其他工单的能力结合起来，突然之间它就真能干事了"。→ 详细
• 串起来之后最值钱的行为是"知道该停下"：同样那个场景完全可能是另一种结果——它在建工单时发现"看起来已经有人做过这件事了，系统里已经有一个开着的 PR"，然后直接告诉你。"它不会一头闷着往前硬推，而是对系统里其他正在发生的事情有感知。" → 详细

• 幂律的成因是目的性：Nan 说因为 Linear 目的性特别强，用例是幂律分布的（少数几个吃掉绝大部分用量）。Linear 的定位是"把公司的意图结构化下来"，最早就是一个 system of record（记录系统，公司里"以它为准"的那份底账）来固化决定。→ 详细
• 头部用例就是"固化决定"的三种形态：① 跟客户开放式聊完，把他们抱怨的几件事提取出来、决定怎么办；② 刚才 demo 的那种讨论转工单；③ "我们改主意了"——开了个重要的会，把会议记录拉出来，一次性更新掉项目 spec 相关的所有内容，"免得做市场之类的同事拿到的是过时信息"。→ 详细
• 长尾里有惊喜：Nan 自己拿它当面试打分器——团队里有份文档写着评估候选人的标准，他把 Granola（会议记录工具）的 MCP 接到 Linear agent 上，就能说"我刚结束的那场面试，照着这份 rubric 快速给我打个分"，省掉从头读笔记。他的总结："只要上下文在某个地方拿得到，你能用它干的事非常多。" → 详细
• 最意外的一类是翻译：很多用户收到自己看不懂的语言的客户反馈就直接让它翻；甚至设成自动化——"我们在法国有很多客户，所以只要来了一条法语的 Intercom ticket，在建工单之前先给我翻译好"。Nan：这些用法"很切题，但我们从来没想到大家会这么用，压根没进过我们的脑子"。→ 详细

• 动机是覆盖完整生命周期：在此之前 Linear 更像平台，你可以把工单指派给 Cursor 之类的外部 agent、在评论里 @ 它们。但 Nan 说"我们接进系统里的那些具体 agent，各自只做其中一段——有的写代码，有的针对 bug 报告做根因分析。但没有一个像我们期望的那样，把整个流程从头到尾走完。" → 详细
• 他们真正想执行的是自己的方法论：以前 Linear 能做的只是写指南（比如那份 "Linear Method"），告诉你该怎么思考软件开发流程。模型能力起来之后看到的机会是："你不用先读一遍、再自己照着这套 playbook 执行，可以直接让 Linear 本身来执行这套 playbook。" → 详细
• 平行宇宙里的另一条路，他们明确放弃了：Nan 直说存在另一种做法——"我们只提供一个 MCP server，你爱用什么客户端连 Linear 就用什么，就完了，没有原生 agent 做任何事"。放弃它的理由是："有一个原生 agent，才能让我们把自己对'什么才是好的产品管理'的观点灌进去。" → 详细
• 争的其实是"默认值"：起因是 Jacob 的一段恐惧——他说模型产 markdown 文件太在行、通常写得特别长，"有时候我干脆不看了，行吧你做个计划去干吧，我最后只看结果"，而"我特别怕的就是，最后越来越多 agent 生成的 markdown 文件堆进 repo 里，而我一个都不看"。Peter 接话："那就全成 slop 了（slop＝AI 产出的没人看的垃圾内容），现实就是这样。"Nan 的回应最关键：常有人说这是"使用者水平问题"、你自己该去读、该告诉它别产垃圾——"话没错，但这又回到那个核心问题：默认值是什么？"好的产品管理"绝不是产出一堆没法读、塞满无关细节的 markdown 文档"。→ 详细
• Peter 的一句话复述（值得贴在墙上）："如果你只做一个 MCP、只给一堆工具让人随便用，他们可能就跑偏了；而 agent 本身带着一堆 skill 和指令，等于把 Linear 的价值观和产品流程注入进去了。"Nan 回："正是。" → 详细

• 长跑 agent 绕不开成本：Jacob 说他们内部确实在试长时间运行的 agent（放手让它一直跑），但"一旦跑这种长时间运行的 agent，成本上的取舍是绕不开的"；同时"我觉得模型已经很接近能把这件事做得很有意思的程度了"。他还确认：你把 Linear Method 传成一个 markdown 文件，agent 确实会读完、也真的会照着做。→ 详细
• Peter 的框架：AI 干中间 80%，人负责最前面的 10% 和最后的 10%；而且可能已经到了"你直接告诉 Linear Agent：这是用户遇到的问题、这是解法的大致思路，你去搞清楚然后提个 PR，我来 review"的程度，哪怕是较大的功能。→ 详细
• Nan 把它推到极端："AI 不是端到端的方案，而是'中间段'的方案。"现在人负责头 10% 尾 10%，"但到某个时候，可能就只剩最前面的 0.1% 和最后收个尾了。中间那段会越来越大，一直大到几乎顶到两头的边界"。关键的一句是后半段："我们假设这件事一定会发生，所以想搭一套能承载它的系统。" → 详细

• 工程视角（Jacob）："感觉我们发得挺早的，不算太早，但我们确实偏向于'已经挺不错了，先放出去，拿更多数据再继续改'。"他给的理由很实在："老实说，这东西留在内部可以打磨到天荒地老都完美不了。像这种主观性很强的东西，很难到达那个所谓'完美'的点。" → 详细
• 产品视角（Nan）：有 UI 的功能和 agent 的质量定义根本不同。做一个 UI 驱动的功能时，"UI 本身就框住了它能干什么"，所以质量定义可以是"把所有你原本没打算让它发生的事都消灭掉"。agent 没有这个边界，所以只能换一套定义。→ 详细
• 换成的定义是"核心招牌用例"：先定几个 hero use case——"我们要拿去 demo 的那些，我们认为能带来很大价值、也最适合大家上手的那些场景"（Peter 列举：建工单、管工单、提 PR，也就是市场宣传里主打的那些）。"只要把这几个做到扎实可靠，剩下的就是：行，可靠性上肯定会有波动，这就是这类工具、这类技术的本性，我们接受这一点。" → 详细
• 他给这条标准起的名字：那几条主推的热路径"可以说是在保修范围内的"。保修范围之外允许波动，之内必须稳——这就是他们发布 agent 时看的质量线。→ 详细
• 发布不是按 eval 全绿来划的：Peter 确认过——他们并没有"只在营销里讲通过全部 eval 的用例"，用户想干别的也随意，"因为它本来就是个 LLM"。→ 详细

• 建议本身（Nan 明确说"我的建议是"）："你得把用户真正想完成的工作流拆开看清楚。很多时候它是超级多步骤的——没有人往桌前一坐，一次就把一整天的活儿一把梭做完，这不可能。"然后再看：哪些地方是天然的切入点，在哪里挂进去才说得通。→ 详细
• 最容易做错的一步：以为 chatbot 就是 agent。"最显而易见的做法是做个应用内 chatbot，然后大家一指——哦，这就是那个 agent。其实那只是跟 agent 交互的一种方式而已。"它是必须的（多轮追问总得有个地方承载），"但入口并不在那儿"。→ 详细
• 入口在哪："入口在你 Slack 里正在进行的那场讨论里，在你的会议纪要里，在你写项目进展、正在做调研的那一刻。那些才是真正的上车口。"给足好入口之后，交互式聊天退化成"后续追问的地方，它覆盖的是长尾需求"。→ 详细
• 不这么做就会撞上的死亡问题：Nan 说得很直白——"否则你就会撞上那个问题：我干嘛不直接用 Claude 或者 ChatGPT 来干这事，而要用你那个原生 agent？" → 详细
• Peter 的类比："agent 有点像一个员工，而员工不会只在一个 app 里干活——你应该能在 Slack 或者你们平时办公的任何地方找他说话。"Nan 认为现在各家都在往这个方向走。→ 详细

• Peter 问 Linear 创始人 Karri 会不会心疼那些精心设计的 UI 被 agent 和 MCP 绕过。Nan："老实说，不会。我觉得他一点都不介意。" → 详细
• 他的理由是 Linear 天然是多人协作系统，不同角色用法本来就不同：做客服的同事跟 Linear 打交道的全部界面就是 Intercom 插件里那几个控件——升级、挑模板、描述问题，就这些。"但这非常有价值，因为这是其他所有人开展工作的输入流。"（Peter 的引申：产品可以 opinionated，但还是得让人从他们习惯的工具里进来。）→ 详细
• 下一步：主动性与长期记忆——Nan 说接下来重点在两块：一是加入一些主动性（proactivity），二是更长期的记忆。设想是：你在公司做一个项目，它可能几天结束也可能持续一整个季度，"agent 应该对这个项目整个生命周期里发生过的一切都了如指掌，并且能很自然地推着它往前走"——协调人、确保文档一直是最新的这些事，"我们希望变成你可以理所当然依赖的东西"。→ 详细
• 他给的目标状态一句话："就像我在 Linear 里跑一个项目，我可以默认它就是被管理得很好的。" → 详细
• Peter 收尾时说了一句所有 PM 都会心一笑的话：每次跟工程师在 Slack 聊了一长串，对方说"好，那把这些同步回 PRD 吧"，他心想"我实在懒得去更新 PRD"——所以能直接把这事派给 Linear 就太有用了。→ 详细

该反着用：Linear 有团队、有生产流量、有一大群真实用户帮他们点踩——所以他们的评测数据集可以等着从用户那里长出来，也敢"先发出去，拿更多数据再改"。你不是。你的 PRD 工厂没有那种用户流，"先发再改"在你这里会直接变成"发了没人用"。正确的反着用是：你的评测数据集必须靠你自己手工种——每次你自己骂 agent 的那一刻，就是那些点踩用户的等价物，你得当场记下来，而不是等一个不存在的用户群。同理，他们敢接受"保修范围外允许波动"，是因为有量能兜住；你的样本量小到每一次翻车都可能砸掉这条流水线的信誉，所以你的保修范围要定得比他们更窄，窄到你能保证每次都稳。

和你现在做法冲突：这是本期最该让你停一下的地方。你的 PRD 工厂是一套高度结构化的协议——三驾马车、互不可见的独立初稿、补强/修正/第 3 案三件交付、六步走完才出稿；而这两个已经把产品做上线的人，一年下来的结论是往越来越少的指令走。更扎心的是那句"我们进这件事的时候，并不觉得自己清楚该造什么，只是说这儿有几个实验、几个方向，那就动手做吧"——你是先把架构图画完了才开始跑的。两边都可能是对的（ERP 领域确实需要比 Linear 更强的约束），但值得你自己回答一次：你那几份 agent 定义里，有多少条是"我们认为该怎么做"的主张，有多少条只是把步骤复述了一遍？后者就是他说的"给它堆太多提示词"。

对你的镜子：Nan 回头看那份 memo 的自评是——"我觉得我们当时不够有野心。我们没想过它能做出多有意思的事。"他们当时给 agent 起的名字叫"机器人项目经理"，定位就是"把无聊的活丢给它"；一年后发现它能交互式地一起干创造性的活。→ 详细 你的 PRD 工厂现在的定位是什么？诚实回答，大概也是"把 PM 写文档这件无聊的活自动化"。同样的不够有野心。值得问自己一遍：如果它不只是替你写 PRD，而是在需求讨论现场就跟你一起把"该不该做这件事"吵明白，你的架构会怎么变？

可迁移的思维模型

• 【耐用】"给工具让它自己去拿上下文，而不是把上下文喂进去"——这是关于"上下文从哪来"的结构性判断，不依赖某一代模型的能力。模型越强，这条越成立。
• 【耐用】"入口不在聊天框，在人本来就在的那个现场"——关于人的工作习惯，跟技术无关，十年后大概率还对。这条也是判断应用层公司站位的尺子。
• 【耐用】"质量标准 = 几条热路径在保修范围内，其余接受波动"——在不确定系统上定义质量的通用方法，也适用于你的自媒体产能账（哪几篇必须稳，其余允许翻车）。
• 【耐用】"评测只用在一致性真的重要的地方"——过度测量制造假信号，测量学的老道理，不会过期。
• 【耐用】"剥掉界面之后还剩什么"——AI 时代软件护城河的一句话检验：还剩输入流和底账的变强，只剩界面的变弱。
• 【会过期】"先上最大模型，跑通后再往下压"——依赖当下的价格梯度。梯度一旦被抹平，这一步就没意义了。
• 【会过期】"用小路由模型把 80% 的请求分流到专用子提示词"——本质是模型不够强时的补丁。别把它写进长期架构，当成本优化手段用就行。

判断更新：你原来大概默认"agent 干得不好 = 上下文喂得不够全"，所以总想把跨线口径一次编全。这期给了已验证的反例——Linear 试过喂全，撞的是上下文爆掉和幻觉；真正解决问题的是"给它自己去查的能力" + "把主张而不是步骤写进 skill"。同时你那个元疑问也有了更准的答法：过时的不是"多视角"，是"多常驻角色"；Linear 的视角比你多得多（上百个 skill），但同一时刻只加载需要的那几片。另外，"agent 产出可验证"这个痛点该重新定义：你缺的不是一次漂亮的演示，是一份从你自己的吐槽里长出来的翻车台账——那才是证据，也正是"会用 evals 的 PM"最便宜的入场券。

这周一个赌注：停手不编词典，改跑一次"砍指令"实验。具体：挑 1 个真实需求，跑两版 PRD——A 版用你现在完整的提示词和背景材料，B 版只留目标 + 一个能检索现有 PRD 和知识库的动作，其余全砍。对比产出、耗时、返工次数，并把过程中每一次"它拿错了东西"记成翻车台账的第一批条目。这一个赌注同时买了四样东西：词典那条路的验证、评测数据集的种子、一人公司账号那篇"我把提示词砍掉 80%"的验证体素材，以及你自己作为"会用 evals 的产品人"的第一份实操记录。