番外篇：反驳——我们让 AI 亲手拆掉整个系列
系列：“我们构建了一条数万行代码的流水线。智能体为何做不到。”
十一篇文章，一个论点。现在，我们让 AI 来把它全部推翻。
上篇：第11篇——证据。投资团队以为又是一次演示。结果拿到了生产系统。决定成败的不是模型——是工程。
Karpathy 测试
Andrej Karpathy 曾经描述过一个让所有写作者都该警惕的工作流：
写了一篇博客。用大语言模型花了 4 个小时反复打磨论点。哇，感觉好棒，太有说服力了！
突发奇想：让它论证相反的观点试试。大语言模型把我整篇论证拆了个干净，让我相信反面才是对的。笑死。
他的结论是：大语言模型极其擅长论证几乎任何方向的观点。它会热情地强化你交给它的任何立场——然后如果你让它反过来，它会同样热情地摧毁它。这其实很有用，但前提是你得主动要求它论证两个方向。
听起来很熟悉。不奇怪。它本质上是人类互联网语言的汇聚。
我们写了十一篇文章，论证组合——大语言模型判断力 + 工程精度 + 人的专业经验——是生产级 AI 系统的正确架构。
但如果这个系列的论点只能在顺风里成立，那它就不值得相信。
所以我们想：来做个 Karpathy 测试吧。把整个系列喂给GPT5.5和Opus4.6：
论证相反的观点。把这个系列拆掉。
以下是模型多轮生成、并经我们反复整理的八个最强反驳，尽可能拟人化地呈现。每一个后面，我们诚实地回应。
反驳 1：你的快照会过时
进攻：你写的是 2026 年初。智能体框架的进步速度，让任何定点评估都不可靠。OpenAI 的函数调用在 2023 年很粗糙，2024 年还行，2025 年已经相当成熟。等读者看到这个系列的时候，“智能体搞不定编排”这个论断可能已经被事实推翻了。你们在打上一场仗。
我们的回应：这是最强的反驳之一，我们认真对待。
没错，智能体会进步。问题是什么类型的进步才重要。如果模型在语义判断上变强——更好地分类链接、理解页面内容、评估相关性——我们的架构直接受益，因为那正是我们已经在用它的那一层。流水线白捡升级。
更难的问题是智能体能否掌握另一部分：跨数千网站的状态管理、预算分配、重试逻辑、优雅降级、robots.txt 合规、PDF 管道管理。这些不是单纯的智能问题，而是工程问题。让模型更聪明不会自动解决它们——只是让模型更擅长解决有人明确定义并验证的部分。
但我们说句实话：两年后边界在哪里，我们不知道。我们知道的是今天，在生产环境中、在机构级规模下，边界在哪里。这个系列记录的就是这个。
判定：部分成立。快照的担忧是合理的。我们尽量聚焦于结构性论点：为什么控制流需要确定性，为什么可审计性需要可追溯性，为什么生产系统需要责任结构。这些不完全依赖于特定模型代际。但某些具体比较确实会过时。写快速变化的领域，这是必然代价。
我们也承认，模型会不断推进边界，很多今天显式写出来的工程结构，未来可能会被更高层的工具和框架吸收。但这并不等于责任结构会自动消失。边界会移动；问题不会因此变得不需要人负责。
反驳 2：不公平比较——精心打磨的流水线 vs. 开箱即用的智能体
进攻：你们花了几个月工程化一条流水线，打磨边界情况，处理各种失败，积累领域知识。然后拿它和一个零迭代时间的通用智能体比较。流水线当然赢。给一个智能体同样的工程投入——定制工具、结构化提示词、反馈循环、错误处理——比较结果就完全不同了。
我们的回应：这个说得对，我们应该更明确。
我们的比较从来不是“我们的流水线 vs. 精心工程化的智能体系统”。而是“我们的流水线 vs. 智能体可以替代工程这个叙事”。
我们反对的绝不是“智能体经过大量工程化后能做有用的事”。当然能。我们自己在构建这条流水线时，也大量使用了 AI 辅助编程：起草实现、解释报错、改写函数、重构局部模块、提出替代方案。很多想法能快速落地，正是因为模型压缩了实现成本。
但压缩实现成本，不等于取消工程责任。关键改动仍然需要人来审核、确认、修改和整合；看似合理的修复，也必须放回整条流水线里，检查它是否破坏了别的模块、流程或隐含契约。
一个精心工程化的智能体系统——有结构化工具、错误处理、状态管理、预算控制、人工监督、可追溯输出和反馈回路——看起来很像什么？
看起来很像一条在关键判断环节使用大语言模型的流水线。也就是我们搭的东西。
甚至可以反过来说：一旦你真的把智能体工程化到可以生产使用，它就不再是“裸智能体”了。它已经变成了一个由工具、规则、状态、日志、预算、反馈和人工责任共同约束的系统。
这时，“精心工程化的智能体”和“在判断环节使用大语言模型的流水线”之间的区别，就会迅速变得模糊。
所以这个反驳真正提醒我们的，不是“流水线比较赢了不公平”，而是：如果要让智能体可靠工作，你最终仍然要把那些被声称可以省掉的工程重新加回来。
我们不反对智能体。我们反对的是：智能体可以消灭它周围的工程这个想法。
判定：在框架层面成立，在实质层面不成立。我们应该更仔细地区分“智能体作为架构”（可以，有时候很好）和“智能体作为工程的替代品”（我们真正反对的东西）。接受批评。
反驳 3：你的 90/10 比例是特定领域的，不具有普遍性
进攻：机构级网络爬取是一个异常偏重编排的领域。数千个网站，每个结构不同，频率限制不同，JavaScript 渲染不同，PDF 处理不同——确定性代码当然占主导。但在代码生成、创意写作、研究综合或客户支持等领域，比例可能是 50/50，甚至 10/90 偏向模型。你们拿一条流水线的经验推广到整个 AI 领域。
我们的回应：这是对的，系列中我们也部分承认了。90/10 的比例是我们领域特有的。在客服聊天机器人里，大语言模型做大部分工作，工程层更薄。在代码生成里，模型承担的份额更大。
况且，如果从开发过程本身看，我们也大量使用了 Opus 辅助编码。也就是说，“90/10”说的是生产系统运行时的职责分工，不是开发者写代码时有没有使用 AI。
我们的反驳点在于：即使在大语言模型主导的领域，工程占比也比人们以为的高。
Cursor 不是“Claude 套个文本框”。Claude Code 也不是“模型会写代码，所以产品自然成立”。这些产品本身就是复杂系统：上下文工程、文件索引、差异管理、多模型编排、工具调用、权限控制、用户体验设计、测试和回滚。90% 在其他领域可能是 70% 或 60%——但永远不会是 0%。
而我们反对的叙事，说它正在趋近于 0。
更深层的观点依然成立：在任何需要可靠性、可追溯性和大规模可审计性的领域，工程占比都会上升。我们的领域恰好把这些要求推到了极限。但受监管的金融、医疗科技和企业软件，需求是类似的。
判定：部分成立。我们应该更明确地说，精确比例因领域而异。原则——工程不会消失——是普遍的。具体数字不是。
反驳 4：专业偏差——你造了你擅长造的东西
进攻：你有工程背景，所以自然会把问题看成工程问题。你擅长搭流水线、做边界控制、处理失败模式，于是最后当然会造出一条重工程流水线，然后说它比智能体可靠。换一个更擅长提示词、智能体编排或模型产品化的团队，也许会得到完全不同的方案。你看到的不是客观最优，而是你自己的专业路径。
我们的回应：这个扎心了，因为有道理。
没错，我们确实带着自己的能力和偏好进入了问题。我们熟悉工程、数据管道、错误处理、可追溯性和生产环境，所以我们更容易看见这些问题，也更自然地用这些方式解决问题。
这点应该承认。
但这个反驳遗漏了一件事：约束不是我们发明的。是投资团队、生产环境和机构要求给出来的。
他们要的是：
- 可审计性；
- 可追溯性；
- 覆盖数千家公司的全面性；
- 可预测的成本；
- 可复现的输出；
- 能进入真实投资流程的结果。
这些不是工程师偏好，而是系统必须满足的条件。
如果一个更擅长智能体系统的团队来做，具体实现可能会不同。它可能使用更多工具调用、更复杂的智能体编排、更自动化的反馈机制。但只要它要进入同样的投资流程、承担同样的审计和责任要求，它最终仍然绕不开这些结构属性：输入要受控，过程要可追溯，输出要可复核，错误要能定位，责任要能归属。
我们也不是一开始就决定要造一条重工程流水线。先试的就是更简单的方案。流水线之所以长出来，正是因为简单方案在用户真正关心的维度上翻车了。
所以，这里确实有专业偏差；但不只是专业偏差。
如果一个方案只是因为我们擅长它而存在，那是偏差。如果一个方案是被真实约束一步步逼出来的，那就是证据。
判定：在观察者偏差层面成立，在生产约束层面不成立。我们应该承认自己的工程背景影响了问题表述和实现路径。但同样的生产要求，会把不同团队的方案推向相似的系统属性：输入受控、过程可追溯、输出可审计、责任可归属。
反驳 5：成本论点是快照，不是趋势
进攻：你们说智能体贵 3–10 倍。但模型成本连续下降。今天让你们流水线显得高效的成本比较，明天就会让它显得贵——因为智能体架构直接受益于成本下降：更多调用变得更便宜。而你们的确定性代码有固定的工程维护成本。经济论点可能在 18 个月内翻转。
我们的回应：成本下降趋势是真实的，我们尊重这个事实。但这个论点混淆了两种不同的成本。
接口成本——每个 token 调用模型的价格——确实在下降。如果智能体系统的唯一成本就是模型调用，这个论点是决定性的。
但大规模运营中，主要成本不只是模型调用成本，而是：
- 调试成本。当智能体在第 2847 个网站上悄悄做了错误决定，你怎么发现？怎么追溯？怎么修复而不影响前 2846 个网站？
- 一致性成本。下个月重新跑流水线，结果可比吗？你能向组合经理解释差异吗？
- 审计成本。当合规部门问“系统为什么把这个页面分类为 ESG 相关？”，你能回答吗？
- 责任成本。当输出进入投资流程，谁能解释、修正和承担结果？
这些成本不会因为模型调用更便宜而自动降低。它们随系统复杂度上升。而智能体架构——如果没有工程约束——会增加系统复杂度，因为每个决策点都可能变成概率分支，而不是确定性分支。
更便宜的模型让智能体更可行用于实验。不会自动让智能体更可审计用于生产。
判定：在接口经济学上部分成立，在总拥有成本上不成立。我们应该把“每次模型调用的成本”和“大规模可靠运营的成本”分开。前者在降。后者没自动下降，而那才是我们论点真正所在的位置。
反驳 6：你在用今天的系统复杂性，对抗明天的抽象
进攻：你整个系列成立的前提是：系统复杂性必须由工程显式承担。但如果未来模型能力继续提升，它可能会吸收越来越多你今天认为必须用代码表达的结构。工具调用、状态跟踪、长时任务、自我纠错，如果逐渐被模型内化，那么你所描述的工程，可能只是“当前能力不足”的替代结构。换句话说：你是在把“暂时需要的工程”，当成“永久必要的工程”。
我们的回应：这是一个非常自然、也非常强的反驳。但它隐含了一个假设：
能力增强 = 系统复杂性减少。
现实情况往往更接近反方向。能力一变强，它通常不是用来解决昨天那个已经定义清楚的问题，而是被立刻用来扩大问题本身。
这也是为什么，即使是今天很强的模型，在一个非常具体的任务上，也常常不是一次性做对。让它根据一张表直接生成图表代码，第一版可能会看错字段、选错图型、处理不好日期、分组或缺失值；后面几轮才逐步修正。问题不只是模型还不够强，而是目标本身往往是在反馈里慢慢变清晰的。
模型可以压缩实现，但不会替你形成目标。它可以展开可能路径，但不会替你决定最终该在哪一条路径上收敛。它没有自己的“停止理由”。
所以我们真正反对的，从来不是“未来模型会更强”。这当然会发生。我们反对的是：把能力上升，直接翻译成系统复杂性会自动消失。很多时候，能力变强带来的，不是工程退场，而是任务升级，反馈回路变长，责任结构变重。
抽象会上移。约束不会消失。
判定：在时间维度上成立，在结构维度上不成立。未来模型会继续吞掉一部分今天显式写出来的结构。但只要目标需要形成、结果需要验收、责任需要归属，系统就不会因为模型更强而自动退场。
反驳 7：目标形成并不是核心问题
进攻：你现在越来越把论点建立在“目标是在反馈中形成的”这件事上：人来判断，人来收敛，人来更新目标。但随着模型能力提升，这件事本身也可能被部分内化。模型已经能提出多个候选方案、比较输出、做自我批评、自我修正，甚至模拟“如果目标其实是另一种”的切换。换句话说：你所说的人负责目标收敛，也许只是当前模型能力的限制，不是一个稳定的结构分工。
我们的回应：这个反驳比“智能体以后会更强”更深，因为它攻击的不是今天的实现，而是最后的结构分工本身。
但这里有一个关键区别：提出候选目标，不等于承担目标；模拟目标更新，不等于决定最终在哪一个上停下。
模型当然可以生成多个方向，甚至可以批评自己的上一版输出。但它做的仍然是扩展可能空间，不是定义哪一个可能空间必须被固定下来。目标形成之所以关键，不是因为人脑比模型更神秘，而是因为目标最终连着代价、责任、取舍和停止条件。
模型可以帮你看见自己原来没说清的东西。它不能替你承担“现在就按这个算”的那一下。很多智能体会帮你做这个，但不一定是你想要的。
所以我们同意：目标形成里有一部分动作会越来越多地被模型吸收。但“形成目标”这件事的最后一跳，不是语义推演，而是责任落点。只要责任还没有被自动化，目标收敛就不会完全被自动化。
判定：在局部动作层面成立，在最终收敛层面不成立。模型会越来越多地参与目标形成过程；但参与过程，不等于拥有最后决定权。
反驳 8：autopilot 的边界会不断扩张
进攻：你区分 autopilot（已成形问题）和 copilot（问题形成中），但这个边界本来就是动态的。随着模型能力提升，越来越多过去需要人协作判断的任务，会被重写成“已成形问题”。而且反馈回路本身也在被自动化：模型可以自测、互测、跑工具、回填错误、继续修正。这样看，copilot 空间会不断被压缩，autopilot 空间会不断扩大。你的框架描述的也许只是一个过渡期。
我们的回应：这也是一个很强的攻击，我们部分接受。
autopilot 的边界当然会扩张。很多今天还需要人盯着的局部任务，几年后会变成稳定的自动化模块。机器—机器反馈也会越来越多，系统会越来越擅长把一些曾经昂贵的人类检查变成常规流水。
但这不等于 copilot 空间会线性消失。
因为每当 autopilot 吞掉一批已经成形的问题，组织和用户通常不会停在原地享受轻松；他们会立刻把能力拿去推更大的范围、更模糊的目标、更长的链条、更重的责任。于是新的“还在形成”的问题又出现了。
边界当然会动，但不是朝着“最终只剩 autopilot”那一种方向动。更多时候，它是在两边同时扩张：自动化吞掉旧任务，现实把新问题推出来。
所以真正稳定的，不是 autopilot 和 copilot 各自覆盖多少比例；而是这个区分本身：
已成形的问题可以更多自动化；还在形成的问题只能协作化。
这条分工线会移动，但不会消失。
判定：在边界会移动这点上成立，在协作会被终结这点上不成立。自动化会扩张；但只要现实持续提出还没成形的问题，copilot 结构就会一直存在。
这个练习证明了什么
八个反驳。没有一个是无聊的。至少三个让我们不舒服。而模型在我们的引导下，经过多轮打磨修正，很快就生成完了。
但这次练习真正重要的地方，不在于我们有没有把它们一一挡回去。
真正重要的是：大语言模型可以在很短时间里生成八个结构完整、各自成立、甚至互相之间并不完全兼容的反驳。它可以同时支持多个互相矛盾但各自合理的世界模型。
这不是缺点。恰恰是它最有用的地方。
模型负责扩展可能性。系统负责压缩可能性。
它不知道哪一个反驳更接近证据，哪一个只是攻击范围；不知道哪一个触及现实约束，哪一个只是攻击表达方式；也不会因为某个判断还没有成形，就主动停在“先别下结论”。它在生成。我们在收敛。
这正是 Karpathy 想提醒人的地方。大语言模型会带着十足的信念论证任何方向。它用同样的热情产出了我们系列的论点。如果我们只让它强化我们的立场——大多数人都这么干——我们会觉得自己是天才。
Karpathy 测试暴露的不只是“大语言模型会讨好你”。它还暴露了大语言模型作为工具的一个底层特征：它很大程度上会沿着你给它的方向、语气、框架和隐含目标继续生成。你让它支持一个观点，它会支持得很漂亮；你让它反驳同一个观点，它也会反驳得很漂亮。
不同产品看起来有不同“性格”，很多时候也是因为系统已经替你注入了一部分默认语气、默认边界和默认偏好。你以为自己只是输入了一个问题，但其实问题本身、系统提示、产品风格和默认安全策略，已经共同塑造了回答的方向。
所以，大语言模型特别擅长做一件事：
把某个方向讲圆。
这很有用。
但它也很危险。
平衡不是判断
很多大语言模型回答最让人烦的地方，不是它错，而是它太会把一切讲得都有道理。
它常常先说“总体上你是对的”，然后立刻补一个“但是”；再列三点说明你为什么对，又列三点说明为什么还要小心。这个结构看起来平衡，也确实经常有帮助。但如果你正在寻找判断，它就会变成一种柔软的拖延：所有东西都被解释了，所有角度都被照顾了，真正的主次却没有被切出来。
现实判断很多时候不是“有没有道理”。几乎任何重要选择，都可以找到正反两面的道理。继续做有继续做的理由，停下来有停下来的理由；快一点有快一点的理由，稳一点有稳一点的理由；自动化有自动化的理由，保留人工判断也有保留人工判断的理由。
模型可以把这些理由都写得很好。它可以无限生成正反两面，无限补充“另一方面”，无限提醒“这取决于具体情况”。
但判断不是把正反两面列全。
判断是：在具体现实里，哪个理由更重？哪个风险你愿意承担？哪个代价你必须接受？什么时候该停，什么时候该继续，什么时候该选一个不完美但足够好的方案？
更麻烦的是，真实判断里的很多权重，根本不以“可列举理由”的形式存在。
人做选择时，通常不会真的把每个因素列出来、逐项打分、求和，然后机械地选择最高分。很多权重来自经验、组织处境、信任关系、过去见过的失败、风险承受能力，以及某种很难完全说清的直觉。
这些东西未必完整存在于互联网文本里。它们可能没有被写下来，也可能写下来时已经失真；甚至做判断的人自己，也未必能把所有权重完全解释清楚。
所以模型可以把正反理由列得很漂亮，却仍然不知道现实里哪一条理由应该更重。
有些人看起来非常谨慎：先讲优点，再讲缺点；过几天又回到优点，再过几天又回到缺点。每一轮都很有道理，但始终没有决定。问题不在于他们没有看到两面，而在于他们没有形成判断。
大语言模型会把这种状态放大。
你以为自己在变得更全面，其实只是让模型帮你在可能性里继续打转。它会让每个方向都显得合理，让每个选择都有补充，让每个结论都有保留。最后，你得到的不是判断，而是一张越来越完整、也越来越难收束的可能性地图。
如果没有一个人最终说：
在这个约束下，我们就按这个方向走。
事情就不会前进。
平衡不是判断。判断是知道什么时候不再继续平衡。
列出理由不是判断。给理由赋权，并承担赋权之后的后果，才是判断。
模型可以帮你看见更多面。
但它不会替你承担选择之后的后果。
这也解释了为什么编程智能体会最先显得特别强。
软件开发不是一个简单领域，但它是一个相对适合智能体发挥的领域：边界更清楚，反馈更密集，工具链更成熟，错误更容易暴露。代码能不能跑，测试能不能过，diff 改了什么，版本能不能回滚，接口有没有破坏，很多时候都有相对明确的检查方式。更重要的是，软件工程几十年来已经积累了大量可被写下来、可被学习、可被工具化的实践。
所以 Claude Code 或 Codex 这类工具看起来像是在“自己做工程判断”，但它们并不是在真空里判断。它们背后站着一个已经高度工程化的软件世界：代码库、测试、版本控制、命令行、错误日志、包管理、工程惯例，以及非常多成熟开发者沉淀下来的偏好。
换句话说，编程智能体之所以强，不只是因为模型强，也因为它被放进了一个相对清晰、可测试、可反馈、可回滚的系统里。
但软件开发只是世界的一个子集。
一旦进入业务判断、投资流程、组织协作、用户需求尚未成形的领域，情况就完全不同。那里未必有现成测试套件，未必有统一正确答案，未必有清楚的偏好函数，也未必有一个成熟工具环境替模型判断：什么更重要，什么不能越界，什么必须保留证据，什么必须交给人判断。
在这些领域，模型当然仍然有用。但它不会自动替你补齐那个缺失的系统层。
如果编程智能体替开发者做了一部分编排和工程，那是因为软件开发领域本身已经有大量编排和工程可以被产品化。到了投资、合规、研究、治理、组织流程这类领域，那部分系统化工作往往还不存在。
于是问题又回来了：
软件开发里的 Claude Code，是别人已经为你做了一部分系统工程。
你的领域里的 Claude Code，可能还需要你自己先把那部分系统工程做出来。
这也是为什么，不能把编程智能体的成功，直接外推成“所有领域都很快会被 agent 自动解决”。越是进入目标不清、反馈稀疏、责任复杂、偏好隐含的领域，越需要有人先把问题空间、证据结构、反馈回路和责任边界做出来。
模型能力很重要。
但模型所在的系统层，同样重要。
这就是第8A篇反复说的委托难题。如果你把论证委托给模型，只让它确认你的观点，你不是在思考——你是在把信念外包给一个没有信念的系统。
但如果你刻意要求最强反驳，坐在不舒服里，在有理的地方更新观点，模型就变成了真正有用的东西。
不是神谕。
是陪练。
更准确地说：当问题已经成形时，它可以更像 autopilot；但当问题本身还要被判断、收敛和更新时，它只能是 copilot。这次练习本质上就是后者。所有攻击路径都可以让模型展开；但没有一条能被自动接受。所有收敛都来自人对证据、结构和现实约束的判断。
我们更新了什么，又没有更新什么
前五个反驳主要攻击的是这个系列的外部边界：时间、比较方式、适用范围、作者偏差和成本趋势。后三个反驳更深，攻击的是结构本身：未来模型会不会吸收工程、目标形成和协作边界。
这不是形式主义。它确实改变了我们后来整理第8篇到第11篇的方式：我们不再只讨论“智能体为什么做不到”，而是更明确地区分了四件事——哪些问题已经成形，哪些目标还在形成，哪些输出需要工程约束，哪些判断必须由人和组织承担责任。
这次练习之后，我们更新了什么：
- 我们会更明确地说 90/10 比例是特定领域的。原则是普遍的。数字不是。
- 我们承认快照问题。这个系列描述的是 2026 年。有些细节会过时，但结构性论点应该存活更久。
- 我们会更清楚地说明反对的到底是什么。不是智能体。不是 AI。是“智能体消灭了对工程的需求”这个具体论断。
- 我们更强调目标形成与责任结构。因为最强的反驳已经不只是“未来模型会更强”，而是“未来模型会不会吸收目标形成和协作边界”。
以下是我们没有更新的：
- 核心论点。组合胜过单打独斗。工程不会消失。大语言模型是工具，不是替代品。
- 证据。投资团队的体验。流水线的生产记录。让它能用的架构属性。
- 结论。搭对。模型做判断，代码做控制，经验定方向。
八个反驳没有一个真正击穿证据本身。它们攻击的是：
- 论点的时效：会不会过时；
- 论点的表达方式：比较是否公平；
- 论点的适用范围：是不是特定领域；
- 论证者的偏差：是不是我们擅长造的东西；
- 论点的成本趋势：会不会被价格变化反转；
- 论点的时间外推：今天的工程会不会被明天的抽象吃掉；
- 论点的目标结构：目标形成是否会被模型吸收；
- 论点的协作边界：autopilot 会不会持续吞掉 copilot。
换句话说，反驳主要击中了三个层面：时间会变，比例会变，边界会变。但它们没有击穿最后一层：生产责任不会因为语言更流畅而自动消失。
这些都是真实的挑战。但没有一个回答最硬的那一层：
这个系统现在能不能在生产环境里交付。
这不是巧合。因为在这个层级上，大语言模型本身也不能生成证据。
因为证据不是语言结构，而是运行结果。
它能生成论证。
不能生成交付。
元教训
整个练习就是系列论点的缩影。
我们用大语言模型生成反驳。它做得非常出色——犀利的、结构清晰的攻击，很快就能生成一版，又一版。很少有人类魔鬼代言人能这么快、这么全面。
但是它还是需要人来评估。判断哪些成立。在有道理的地方更新。在有证据支撑的地方坚持立场。这次练习并不是几十秒完成的；模型很快扩展了可能性，但人花了很多天，才判断哪些东西真正成熟、哪些地方应该更新、哪些结论仍然站得住。
大语言模型提供了可能空间。人提供了收敛方向。组合产出了两者单独都做不出的东西。
所以最后真正稳住这个系列的，不是我们能不能写出更漂亮的论证，而是第11篇里的那件事：系统进入了真实团队的时间表、判断流程和责任结构。
这也是为什么，这篇番外到最后已经不再只是“我们守住了原来的结论”。它更像是用一次反驳实验，重新证明了整个系列一直在说的结构：
模型可以扩展可能性。系统负责压缩可能性。
AI 擅长理解语义。代码擅长保证行为。经验决定什么时候用哪个。三者缺一不可。
写关于搭这条流水线的博客系列的模式，其实也一样。
主线终点：→ 第11篇：证据
从头开始阅读：→ 第1篇：不可能的任务
其他番外：→ 番外篇：站在中间地带 · 番外篇：理解系统，才有资格委托系统