你那套AI自动化不是哪天突然坏的，它从第二周就开始走形，而那批页面早已进了索引

摘要： 不懂技术的人能搭出相当复杂的AI系统，这件事已经不新鲜。新鲜的是这类系统的坏法：它很少在某一天崩掉，而是从第二周起一点点走形——连接过期、映射表被人改过、口径悄悄偏离，产出照样按时交上来。放在企业内部，走形的后果是同事看到一份错日报；放在独立站，走形期的产出是已经上线、已经被抓取、已经躺进索引的页面。这篇讲这条走形曲线怎么认、授权为什么该按目录切而不是按功能切、十四项体检怎么排，以及我那条流水线静默错了三个月、最后被销售一句吐槽揪出来的全过程。

不懂技术的人现在能搭出什么东西？

先把这批人是谁说清楚。他们不是在用AI写文案，是在搭系统，而独立站主几乎逐条对得上这个画像。

那七个人到底搭出了什么东西？

尼尔森诺曼集团在2026年6月发了一项研究，题目叫Vibe Architects，招了七个非技术背景的人，看他们怎么用开放式的智能体工具干活。

结果比预想的野。一位运营专员在给团队搭自动化管道，顺手把网页应用也部署上线了。一位在金融机构做产品设计的人，晚上和周末给自己写小工具。一位营销创业公司的创始人跑着一套无界面的编排系统，能主动给他提建议，还能协调多个智能体。

最狠的是一位产品负责人：他把整个团队搬进了一套基于Claude的操作系统里，会议、信息共享、决策流程，全在里面走。

这几个人都不写代码。

研究者给他们起了个名字，叫氛围架构师。这个叫法比氛围编程往前挪了一大步：氛围编程好歹还是在写一个程序，氛围架构师是在设计信息怎么在系统间流动、智能体怎么分工、活儿按什么顺序走完——有时候还是替一整个团队设计的。

招不到人这件事，本身就是结论？

研究里有个细节容易被跳过。研究者原本想招那种既不是开发者、也不在数字设计和产品这个行当里的人，结果七个非技术背景的人是找到了，行业外的人却几乎招不到。

他们自己在文章里承认，这可能暗示了这类人有多稀少。

这句话值得停一下。不是说没人在用AI，是说能把AI用到搭出一套自运转系统的人，目前还集中在离技术圈很近的那一层：有懂技术的朋友，有大把时间试，也有足够动机撑过前面那段一无所获的日子。

换句话说，你在社交平台上刷到的那些一个人跑通全流程的案例，样本本身就是筛过的。

独立站主为什么天生就是这批人？

把研究里那四个画像翻译一下，你会发现独立站主和外贸运营几乎逐条对得上。

• 手上活多得干不完，没有开发资源可调，只能自己上手
• 业务逻辑全在自己脑子里，讲给别人听比自己做一遍还慢
• 工具预算有限，但试错成本几乎为零，反正跑坏了重开一个对话
• 没有任何人给你排期、评审、验收，你既是需求方也是唯一的交付方

研究里那位晚上给自己写工具的产品设计师，和一个周末给站上批量生成分类页文案的独立站主，是同一种人。差别只是后者的产出会被搜索引擎抓走。

所以这篇文章不是在讲别人的故事。你要是这两年碰过任何一个能自己跑起来的脚本或者工作流，那你已经在这条曲线上了。

你搭的东西，可能比你以为的更像一套系统？

很多人不承认自己搭了系统，因为他们心里的系统长着后台界面和登录框。

研究里有个画面很有意思：一位参与者给研究者展示了自己做的仪表盘，然后顺口说他其实不怎么看这个东西，日常都在代码环境和对话窗口里干活。那个传统界面是事后才想起来补的。

独立站这边的对应形态是：几个提示词文件、一份产品线对照表、两个定时任务、一段调接口的脚本、一个存中间结果的表格。它们分散在不同地方，没有名字，没有文档，但它们互相依赖，缺一个就转不动。

这就是一套系统。它没有界面，不代表它没有状态。

界面成了事后才想起来的那一层？

这个变化对做网站的人有一层特别的含义。

过去二十年，我们判断一个东西做没做好，靠的是看它：页面长什么样、按钮在哪、有没有错位。这套方法在自动化系统面前直接失效——它压根没有可看的表面。

研究里的系统有的活在Markdown文本文件里，有的活在对话记录里。你没法截图，没法请人扫一眼帮你挑错，也没法靠肉眼发现哪里不对。

顺便说一句，这个道理和智能体读网页的方式是同一回事：机器读的是结构不是像素，而智能体读的是无障碍树不是页面截图那篇讲的是外部智能体怎么看你的站，这里讲的是你自己搭的那套东西你根本看不见。两头都在往同一个方向走：可看的部分越来越不重要。

手感不等于知识，那个省token的误会说明了什么？

研究里记了一个特别典型的误会。

一位参与者养成了一个习惯：每次想重置对话，她就把整段历史对话复制进一个新对话的提示词里。她认为这么做省token。

实际上长对话确实更费token，但把上下文塞进一个超长提示词里同样费。她这套做法基本上是把钱从左口袋倒进右口袋，还多走了一趟。

研究者对这类现象的判断是：这些直觉不总是准的，它们反映的是模糊的心智模型，有时候真能出结果，有时候什么用也没有。

手感是真的，手感带来的产出也是真的，但手感里混着的错误认知不会自己浮出来。它会一直待在那儿，直到某个后果大到你不得不回头查。

既然这么糙，这套东西凭什么还值得搭？

研究者自己给了答案，而且答得挺公道：这些拼凑起来的系统，价值恰恰在于它们有多贴身。

氛围架构师知道自己那套东西乱，但它是照着自己的活长出来的，需求一变就能跟着改。原文里那句话很妙——它可能是座纸牌屋，但仍然是座有用的纸牌屋。

保哥的判断是，这个便宜占得非常实。一个外贸运营花两天糊出来的报价单批处理，效率上大概率打不过任何一套正规软件，但它省下的那部分沟通成本、等排期的时间、解释需求的来回，正规软件一分钱也帮你省不了。

所以这篇不打算劝你别搭。劝你别搭是最没用的建议，因为你不搭，活就没人干。

那这篇到底想讲什么？

讲搭完之后的那一段。

市面上关于怎么搭的东西已经很多了：用氛围编程做SEO工具的八步避坑流程讲从零到一怎么把工具做出来，用Claude Code搭一套会替你干活的运营系统讲记忆层、检索层、技能层和心跳层怎么依次装起来。这两篇的终点，正好是本文的起点。

还有一个相邻但不同的问题也已经讲过：一个人靠AI跑通一支营销团队之后门槛变在哪回答的是能不能顶得起来、护城河从产能挪到了判断上。本文接着往下问一句：顶起来之后，那套东西凭什么守得住。能搭和能守是两种完全不同的本事，而后者几乎没人讲。

因为搭起来那天不是结束，是这套东西开始变质的第一天。

系统不是某天崩掉的，它是怎么一点点走形的？

这一节是全文的主轴：从上线到重搭之间有三个性质完全不同的阶段，最贵的那一段恰好最不像出问题。

系统不是某天坏掉的，那它是怎么走形的？

研究里有句抱怨被我反复读了好几遍。

那位把团队搬进Claude的产品负责人说，他那套东西能撑几个星期，然后衰败就来了，只能把流程重新搭一遍。另一位参与者形容同一个现象是漂移：随着自己不断往里加东西，它会开始跑偏，管住这个比原来更难。

研究者把这段归在维护负担里，一句话带过——连接过期、上下文跑偏、单一事实源失去同步，让整套东西转起来变成了持续消耗架构师时间的一项税。

这一句在我看来不该只是一句。它是这类系统最核心的性质，只不过在一篇讲用户体验的研究里没地方展开。

蜜月期为什么会给你一个错的信号？

第一到第二周，这套东西一般表现极好。

原因不神秘：所有输入都是你刚刚亲手对齐过的，所有接口都是刚连上的，所有规则都还在你的短期记忆里。这时候产出质量高，你的判断也准，因为你能一眼看出哪里不对。

问题是你会把这段表现当成这套系统的常态，然后据此做两个决定：扩大它的使用范围，以及降低检查频率。

两个决定单独看都合理，凑在一起就是后面所有麻烦的起点：出错面变宽，发现变慢，而这两件事恰好同时发生。

走形期长什么样：产出还在，口径已经偏了？

第三到第八周是最贵的一段，因为它一点也不像出问题。

定时任务照跑，日志里没有报错，产出文件按时出现在该出现的地方，数量甚至比蜜月期还多。变的是内容里的某几个值：型号对不上了，适用范围写宽了，运费口径用的是上个季度的，某个分类的文案套用了最接近的另一个分类。

这些错误有个共同特征——它们都是合理的错误。它们语法通顺、格式正确、逻辑自洽，唯一的问题是不对。

而你的检查方式此刻已经退化成抽查了。抽查最容易漏掉的恰好是这一类，因为抽到的那一条看上去完全没问题。

塌方期为什么反而是最便宜的那一段？

第八周之后，某个接口的令牌过期了，或者某个文件被改成了它读不懂的格式，或者上游把字段名换了。任务开始报错，产出断了。

这时候你会骂一句，然后花一天半把它重新搭起来。

听起来这是最糟的一段，其实这是最好的一段。因为塌方是有声的：它有明确的时间点、明确的报错、明确的责任人（你），而且它自己会停下来，不会继续往外产东西。

真正吃掉你钱的是前面那五六周——它一声不响，还很勤快。

每几周就得重搭一次，这句话该怎么读？

研究里那位产品负责人说的重新搭一遍，字面意思是重建流程。但真正被重建的不是流程，是他脑子里关于这套系统当前状态的那份认知。

这两件事花的时间差得很远。改配置、换令牌、修文件格式，快的话半小时。重新弄清楚这套东西现在到底在读哪份表、哪几条规则还生效、上次是谁改了什么，可能要一整天。

而后者是没法交接的。这就解释了为什么这类系统在人手上有极强的绑定性：不是别人学不会怎么操作，是别人不知道它现在处在什么状态。

走形的五个源头，哪个最常见？

把我这两年见过的走形归一下类，大致是五个来源，按发生频率从高到低排：

1. 输入源被改过：某张对照表、价目表、规格表被人（常常是你自己）改了一次，系统不知道，继续按旧的读
2. 上下文被塞满：能塞的东西越塞越多，关键约束被埋在中间，模型的注意力分不过来
3. 规则文件被系统自己改过：你让它自己维护配置，它就真的会改，而且不一定告诉你
4. 模型换代：同一段提示词，新模型的解读方式变了，输出风格和详略程度跟着变
5. 连接与凭据到期：这一类最容易发现，因为它会直接报错

注意这个排序：最容易发现的排在最后，最常发生的排在最前，而且第一条几乎不产生任何可观测信号。你的监控体系通常只盖住了第五条。

那份没人认领的单一事实源，是怎么分叉的？

单一事实源这个词在讲数据治理的时候很清楚，SEO指标层怎么定一份靠得住的口径那篇专门讲过怎么把指标收敛到一处。

但在独立站的自动化场景里，它有个更具体的形态。同一条产品规格，通常同时住在五个地方：

• 后台的产品字段里
• 导给渠道的数据源文件里
• 页面上的结构化数据标记里
• AI客服读的那份知识库里
• 分类页和对比模块的文案里

你改了第一个，剩下四个各按自己的节奏更新。而搜索引擎和外部模型抓到的，恰好是后面那四个。

更麻烦的是没人认领这件事。这五份东西分别由五个流程产出，每个流程都觉得自己读的是权威版本。

走形和你熟悉的那几种衰减，差在哪？

站上讲过好几种会自己变坏的东西，值得摆在一起分清。

内链权重会漏进分页和重定向链讲的是链接图的熵增，没有任何AI参与，成因是导航改版、分页、跳转累积。搜索意图漂移怎么识别和应对讲的是需求侧变了，你的页面没动。

本文这条不一样：系统本身没变，输入变了，于是它继续正确地执行着一个已经过时的指令。

这三种坏法的诊断入口完全不同。内链衰减靠爬站，意图漂移靠看搜索结果页，走形只能靠回溯输入源的版本。而输入源恰好是三者里唯一不留痕迹的那个。

同一套系统走形，为什么独立站的代价大得多？

企业内部走形，后果是一份错日报；你的走形有个收件人叫索引。这一节讲这个差别具体贵在哪几处。

同样一套系统走形，为什么独立站比企业更吃亏？

研究里那七位，除了一位创业公司创始人，其余都在企业内部干活。他们的系统走形之后，后果是同事看到一份口径不对的日报，或者某个决策依据错了，然后有人在群里问一句这数不对吧。

这个后果有个极其宝贵的性质：它可以撤回。发现错了，重发一份，说声抱歉，事情结束。

独立站的走形有个别的收件人。它叫索引。

你那套批量生成的东西一旦发出去，就进入了一条你控制不了的管线：抓取、解析、入库、评估、排序、被外部模型检索、被复述。这条管线上每一步都不问你后不后悔。

这是本文和AI给的结论你不敢往上线推那篇最大的分工：那篇讲的是签字放行之前你该向系统索要什么交代，属于准入时刻；这篇讲的是签完字之后那六个星期，属于运行期。准入做得再干净，也不能替你盯住运行期。

走形期的产出，会在索引里堆成什么？

算笔账。假设你那套流水线每天出二十页，走形期六周，那就是八百四十页。

这八百四十页不是八百四十个孤立的错误。它们出自同一批规则、同一份旧输入源，错法高度一致，还会互相内链、共用同一套模板文案，最后堆成一个内部完全自洽的小地层。

自洽是这里最坏的一个词。因为你排查的时候，交叉验证会告诉你没问题——这一页说的和那一页说的一模一样。

它们一致，只是一致地错。

为什么删掉不等于修好？

发现之后最自然的动作是把那批页面删了或者重写。这一步必须做，但它只解决了一半。

另一半在你的站外面：

• 这批页面可能已经被别人引用、截图、转述过
• 外部AI引擎可能已经把那个错值收进了自己的答案里，而它不会因为你改了页面就立刻改口
• 比价站、聚合站、渠道的数据源可能已经同步过一轮旧值
• 你自己的其他流程可能反过来读了这批页面，把错值又抄了一遍

最后一条最阴。系统之间互相读，错值会绕一圈回到源头，这时候你连它是从哪儿来的都说不清了。

关于怎么把已经跑出去的错事实追回来，AI说错了你的品牌事实怎么办那篇给了完整的溯源和纠错路径，这里就不重复了。要记的是：纠错的成本远高于产出的成本，通常差一个量级。

从走形到掉量，中间要走完几段路？

很多人觉得改错了就该马上掉量，掉了才好办事。现实是它慢得让人难受。

四段加起来两三个月很正常。等你终于确认有问题，走形期早结束了，你面对的是一个凉掉的现场。

这就是为什么走形必须在产出阶段被抓住。往后每挪一段，取证难度都翻倍。

为什么这批页面还会抢走正确页面的位置？

还有个容易漏的代价。走形期产出的页面，通常和你原有的正确页面盖着同一批词。

它们数量多、生成时间新、结构统一，在某些判断里反而更占优势。结果是它们把原来那批人工写过、转化数据也不错的页面挤了下去。

于是你会看到一个很怪的现象：整体收录页数涨了，展现量也涨了，可下单的那几个页面的排名在往下走。看总量什么问题都看不出来。

这一层归到自我竞争里更合适。要点是：走形期的产出不是中性的增量，它是带侵占性的。

结构化数据走形，为什么是里面最硬的一条违规？

五个走形形态里，结构化数据这一条性质不一样——它不是效果差，它是明确违规。

Google在结构化数据通用准则里把标记必须能代表页面主要内容、必须与用户可见的内容一致写进了规范。也就是说，你的标记里写着一个价格、页面上显示着另一个，这本身就够格被处理，不用等它影响体验。

而自动生成结构化数据恰好是最容易被交给流水线的活，因为它格式固定、看着最不需要判断。

更麻烦的是校验工具帮不了你。校验器只检查语法和必填字段，它不知道你那个价格是不是上个季度的。校验通过和内容正确，是两码事。

多语言站的走形，为什么可能一直没人发现？

做出海的还多一层，而且这一层的静默程度是最高的。

一份产品规格改了，主语言站更新了，其余六七个语种的版本按各自的节奏跟。跟得慢的那个语种，走形期能拉到一个季度以上。

更要紧的是，小语种页面上的错误没有读者能替你发现。中文和英文页面写错了型号，多少还有人看得出来；泰语、波兰语、乌克兰语那几个版本，你团队里可能一个能读的人都没有。走形在那儿不是难发现，是结构上不可能被发现——除了它自己产生询盘的时候。

所以多语种站的体检必须换个抓手：别指望读内容，去比数值。型号编号、尺寸数字、认证编号、价格这几类是跨语言不变的，把各语种版本里的这些值横着摊开对一遍，不懂那门语言也能发现问题。

关税和时效这类值，为什么算会自己过期的输入源？

前面说的五个走形源头里，输入源被改过排第一。跨境场景还有个变种更麻烦：输入源没人改，它自己就过期了。

典型的有这几类：

• 关税与税则口径，随政策调整，你不改它也会不准
• 运费和时效，承运商调价或者旺季一到就变，而页面上写的是旧区间
• 各市场的认证名称与编号，跨市场绝对不能通用，而自动化最爱跨市场套用
• 库存与交期，变化频率高到没有任何静态文案追得上

这类值的正确处置不是提高更新频率，是改写法。给区间、给口径、给截止日期，比给一个精确数字安全得多。写截至某月某日、按某承运商标准渠道、不含清关等待，比写七到十天可靠——后者一定会在某个时点变成假话。

认证那一条尤其要划红线，因为它走形之后的后果不止是SEO。跨市场套用认证名称属于合规问题，它不在本文的补救范围里，只能靠权限拦住：认证字段永不进自动生成的范围。

外部AI引擎的记性，为什么比搜索引擎更长？

传统搜索里，页面改了，重抓之后旧内容基本就退场了。生成式引擎这边不太一样。

一段被引用过的表述可能已经进了别人的答案、别人的转述、别人的整理帖。等你改完页面，它还在别处继续被复述，而复述的那份没有更新机制。

这一层的应对不在本文范围，AEO靠六个自动化环节持续盯防讲的是怎么把这种监控常态化。这里只需要接受一个前提：你的错值在站外的半衰期，比在站内长得多。

所以独立站的走形代价，是按什么方式长大的？

说个我自己在算账时才想明白的事。走形的代价不是随时间线性增长的。

因为叠加的不是页面数量，是页面数量乘以每页被读到的次数。走形第一周产出的页面，到第六周已经被抓了好几轮、被内链指了好几次、可能已经被外部引用过。它们在系统里的分量随时间自己长。

换个说法：早期的错误比晚期的错误贵得多，而早期的错误恰好是最难发现的，因为那时候你还在蜜月期的自信里。

这条推论直接决定了后面所有做法的优先级——所有资源都该压在缩短发现时间上，而不是压在提高单次产出质量上。这两件事经常被当成一件事，其实完全不是。

授权为什么该按目录切，而不是按功能切？

从研究里那句它只有这个文件夹的上下文讲起，到一份永不给写权限的路径清单和决定放不放手的四个问题。

那句它只有这个文件夹的上下文，问题出在哪？

研究里有一段实录，我认为是整篇里对独立站最有杀伤力的一段。

一位参与者在共享屏幕，编辑器里的智能体正在给她团队做东西，不停弹出请求权限的提示。她一边和研究者说话，一边反复点接受，看都不看内容。研究者问她平时是不是也这样，她说是。

她的解释是：她不想开放那个危险级别的权限，所以大部分时候，哪怕不明白它在问什么，她也直接点同意——因为它只有这个文件夹的上下文，所以她不太需要担心它去碰别的东西。

这个推理有一个前提和一个结论。前提是它的活动范围被限制在一个文件夹里，结论是范围既然有限，那单次批准的风险就有限。

前提成立，结论在很多场景下也成立。它在一种场景下彻底不成立：当那个文件夹就是你的网站根目录的时候。

危险级别这个标签，为什么是整份研究里最成功的设计？

研究者顺手记了一笔挺有意思的观察。那个用来阻止人们放开全部限制的选项，名字里带着危险两个字，而它显然相当有效——参与者明确表示自己不用那个级别。

换句话说，一个措辞把一大类事故挡在了外面，效果好过后面那一整套逐次确认的机制。因为逐次确认最终被点成了肌肉记忆，而那个带危险字样的开关她压根没碰。

这条对我们做站的人有直接的启发：不可逆的操作应该靠命名和位置挡住，可逆的操作才适合靠确认挡住。把不可逆的东西也放进确认流，等于把它交给了一个注定会疲劳的人。

顺便说，研究里还有一位参与者因为反复点接受把手点出了腕管综合征。这个细节像段子，但它准确描述了确认机制的真实寿命：它撑不到你手酸。

网站根目录里，都躺着些什么？

把只有这个文件夹的上下文这句话放到独立站的现场，列一下那个文件夹里通常有什么：

• robots.txt，一行写错就能把整站挡在抓取之外
• 站点地图与它的生成脚本
• 重写规则和重定向表，改错一条能把一批页面送进循环跳转
• 主题模板文件，动一个标签影响的是全站每一页的头部
• 各种配置文件，里头常常带着数据库和接口凭据
• 那份被所有流程读取的产品对照表

这里面每一项的影响面都是全站级的，而且大部分改动不会立刻表现出任何异常。页面还是能打开，返回码还是那个熟悉的数字。

所以那位参与者的判断在她的场景里是对的，搬到根目录下就反了：这个文件夹的上下文，恰好就是全部的上下文。

权限按功能划为什么划不清，按目录才划得清？

大部分人第一次给自动化系统设权限，是按功能想的：可以改元数据，不可以改重定向。

这种划法执行不了。改元数据不是一个可枚举的动作集合，它是个含义模糊的名词。模板里那段输出标题的代码算不算？给分类页批量加描述算不算？两个人能吵一整天。

目录不一样，它是物理的、可枚举的、能写成规则的。你可以确定地说这个路径下永不允许写入，然后让它在配置里变成硬规则，而不是一条你希望自己会记住的原则。

这也是Claude Code那套权限设计的思路。Claude Code设置文档里的权限规则是按工具加路径模式来写允许和拒绝的，拒绝规则优先级高于允许规则。把最狠的几条路径先写进拒绝列表，比记住自己不要手滑靠得住得多。

哪些路径应该永远拿不到写权限？

给一份可以直接照抄的起点。左边是路径类型，右边是理由——理由比清单本身重要，因为你的站结构和我不一样，但判断标准是通的。

最后一条最容易被漏掉，因为它看着只是一张表。但它是整套系统里唯一被所有人读、没有任何人负责的东西。

决定放不放手，该问哪四个问题？

比清单更耐用的是判断方法。我现在决定一件事要不要交给自动化，只问四个问题：

1. 出错多久才现形？当场就能看见的，可以放；隔一个抓取周期才现形的，加一道人工
2. 谁会先发现，人还是机器？用户会投诉的，风险自带报警；只有引擎看得见的，报警得你自己造
3. 能不能一键回滚？有版本、有快照、能一条命令回去的，可以放；靠手工复原的，不放
4. 撤销成本是多少？撤销只需要改回来的，可以放；撤销需要重新建立信任的，不放

四个问题里只要有一个答不上来，这件事就先别自动化。注意这四问问的全是出错之后，一个字没问准确率。

这是故意的。准确率是准入指标，可逆性是运行期指标，而走形只发生在运行期。一个九成五准确但不可逆的动作，比一个八成准确但能一键回滚的动作危险得多。

自动模式解决了什么，又没解决什么？

研究做完不久，Claude Code上了自动模式，会自动批准那些不具破坏性和风险的请求，只在特定动作上才停下来问你。研究者还开了句玩笑，希望参与者们发现这个功能，好救救他们的手指。

这个功能确实解决了点击疲劳，方向完全对。但它解决的是疲劳，不是判断。

什么算破坏性，这个判断现在由工具替你做了。工具的默认判断是通用的：删文件危险，写文件不危险。它不知道你这个站里改一行robots比删十个文件严重得多。

所以自动模式的正确用法是：先把你自己那份路径级的拒绝规则写死，再打开它。顺序反过来，你就是把判断权和疲劳一起交出去了。

那个boundaries.md的故事，到底说明了什么？

研究里还有一段，我读到的时候后背有点凉。

一位参与者的智能体头一晚试图完成一笔两百美元的采购。研究者问他怎么防这类事，他开始在文件里翻找，不太确定到底是什么在管着这套系统。最后他找到一个叫边界的文件，里面是安全和隐私方面的规则。他打开看，对内容感到意外——这文件不是他写的，是模型自己建立并一直维护的，他的角色是事后追认。

这件事有两层。表层是他不知道自己的护栏长什么样。深层更要紧：他那套系统的治理规则，是系统自己的产出物之一。

而产出物会走形。一份由系统自己维护的规则文件，没有任何理由比它维护的其他文件更稳定。你以为那是地基，其实那也是楼上的一层。

所以规则文件必须由人写、由人改、并且放在系统拿不到写权限的路径下。这一条我认为是整篇里优先级最高的一条。关于规则文件本身怎么写才清楚，CLAUDE.md怎么写才能让AI每次都听话那篇讲了结构和模板，这里只强调一件事：写完之后，别让它自己改。

走形是静默的，你靠什么把它变成有声的？

现有监控结构上就抓不到走形。这一节给基线怎么采、十四项体检怎么按周月季排，以及该配着看的那两个数字。

为什么不能等着后台给你报错？

先说清一件事，免得后面那张表被当成又一份可选清单：现有的监控体系结构上就抓不到走形。

搜索后台报的是抓取失败、标记语法错误、可索引状态异常这类可判定的问题。它有没有能力判断你那个型号写错了？没有。它不知道你的正确答案是什么。

服务器监控看响应码和响应时间，走形期的页面这两项完美。校验器看必填字段和格式，走形期的标记全部通过。数据后台看流量趋势，而流量要等两三个月才动。

所以走形是一个没有现成传感器的故障类型。你不给它装一个，它就永远是静默的。这不是勤快不勤快的问题，是有没有信号的问题。

让静默失败变成有声，第一步该做什么？

做自动化的人对这件事其实早有共识，只是SEO这边引进得慢。

n8n的文档里有一节专门讲这个，标题就叫优雅地处理错误：给工作流配一条专门的错误流程，让失败的执行主动通知你，而不是安静地躺在执行历史里等你去翻。

这个思路挪到我们这边，要补的正是最关键的那一句：失败要能自己喊出来。而走形之所以难办，是因为它连失败都算不上——每一步都成功了。

所以我们要造的不是错误通知，是意外通知。不是这一步跑没跑通，而是这一步的产出跟上一次比，变没变得离谱。这两种通知的实现方式完全不同：前者监听异常，后者对比基线。

基线该在什么时候采，采什么？

基线要在蜜月期采。这是唯一一个你确定输出是对的时间窗，过了就没有了。

具体做法不复杂：系统跑顺的第一周，把当周的产出整体存一份，同时记下四类数值。

• 产出条数、平均长度、字段填充率这类形状指标
• 被引用的输入源清单，以及每份源当时的修改时间
• 关键字段的取值分布，比如型号出现的种类数、价格区间、适用范围的枚举值
• 你自己抽检二十条并判定为正确的那份样本，原文存好

第四项最容易被省，也最有用。往后每次怀疑走形，你要的不是重新定义什么叫对，而是一份当年被你亲手判定为对的东西。

关于取样该抽多少、多久抽一次才不浪费钱，排名追踪的抽样设计与频率取舍那篇的思路可以直接搬过来用，抽样这件事的经济学在哪个场景都一样。

每周该看的四项是什么？

下面这十四项按频率分三档。每周这四项花不到二十分钟，它们负责抓最常见、最便宜的那几种走形。

1. 输入源的修改时间：所有被读取的表格和配置，最近修改时间是否晚于你上次确认它的时间。这一项抓的是第一大走形源头，成本却接近于零
2. 产出条数与形状：本周产出条数、平均长度和上周比，偏离超过两成就停下来看一眼
3. 新出现的取值：关键字段里出现了基线里没有的枚举值——新型号、新分类名、新单位。新值不一定是错的，但它一定值得确认
4. 规则文件的修改记录：那几个提示词和配置文件，这周有没有被谁改过。谁包括系统自己

四项里有三项看的是输入和规则，不是产出。这是故意的：查产出是大海捞针，查输入是查一个短名单。

每月该看的五项是什么？

每月这五项要花两小时左右，负责抓那些累积型的走形。

1. 二十条抽检对比基线：按同样的抽法抽二十条，逐条和基线那份样本比，重点看事实类字段而不是文风
2. 五处口径一致性：拿三个热门型号，把后台字段、渠道数据源、页面标记、客服知识库、分类页文案五处的值摊开对
3. 凭据与连接的到期表：所有令牌、接口密钥、授权的到期日列一张表，提前两周处理
4. 上下文文件的体积：喂给系统的那几份资料是不是越塞越厚。厚到一定程度，前面的约束就开始不生效了
5. 产出与人工版的差距：自己动手写两条同类产出，和系统写的比。差距在变大还是变小，这个感觉骗不了人

第二项是这五项里最值钱的。AI客服翻出三年前的废弃文档那篇讲的是喂进去的资料该怎么组织，这里查的是同一份资料在五个出口有没有说成五个版本。组织得再好，出口不一致照样白搭。

每季该看的五项是什么？

每季这五项是给整套系统做体检，不是查某次产出。

1. 权限清单复核：那份永不给写权限的路径表，还准确吗。这一季有没有新目录悄悄进了可写范围
2. 模型换代影响：底层模型这一季有没有升级。升级了就拿基线那二十条重跑一遍，比输出
3. 还剩几个人能修：这套东西现在除了你，有几个人能在两小时内讲清它读哪些源、按什么顺序跑
4. 废弃分支清理：那些当初试过、后来不用了却还在跑的任务和文件，全部关掉。它们是走形的温床
5. 重搭成本估算：假设今天全塌，重新搭起来要多久。这个数字比任何满意度都能说明系统的健康程度

第四项被低估得厉害。废弃的分支不会报错，它们只会在某个不合适的时刻把过时的东西喂给下游，然后你会花两天找一个根本不该存在的源头。

输入源为什么必须能自己声明版本？

整套体检里，只有一件事是结构性的改造，其余都是习惯。这件事就是给输入源上版本。

做法可以极其土。在每份被读取的表格顶部加两行：版本号，最后修改日期。然后让流水线在每次运行时把这两行连同产出一起记下来。

就这么两行，效果是决定性的。它把走形从不可观测变成了可观测——出问题时你能立刻回答那批页面当时读的是哪一版，而不是靠猜。

更进一步的话，让流水线在版本号变化时主动停一次，等你确认。这一停通常只花你三十秒，省下的是后面几个星期的静默产出。

我把这条排在整篇的第二优先级，仅次于规则文件不许系统自己改。这两条都不需要新工具，只需要你今天下午动一次手。

该配着看的两个指标是什么？

最后给两个数字。单独看任何一个都会误导你，配着看才有意义。

第一个是首次走形间隔：从系统上线到你第一次抓到确凿的口径偏离，隔了多少天。这个数字越小越好，因为它衡量的是你的发现能力，不是系统的稳定性。

第二个是每次重搭的人工小时：每次修好它平均花你多久。这个数字越小越好，它衡量的是这套东西可不可维护。

为什么要配着看？因为它们能被单独作弊。间隔天数可以靠不去查来做得很好看——不查就永远查不到。重搭小时可以靠不修来做得很好看——凑合用着也能跑。

两个一起看就没法糊弄了：间隔短说明你盯得住，重搭快说明它修得动。前者短后者长，说明这套东西该重构了；前者长后者短，说明你压根没在盯。这个思路和客服机器人那两个必须配着看的指标是同一套逻辑：凡是能靠不作为改善的数字，都不能单独当考核项。

我那条流水线，是怎么静默错了三个月的？

一次完整的失手复盘：一张表、一个低级的缓存条件、四十多个页面，最后靠销售一句吐槽才浮出来。

那条流水线原本干得挺好，好到什么程度？

说个我自己的现场。客户是个做园艺与庭院工具的出海站，一千四百多个SKU，按产品线和应用场景交叉切出六十来个分类页。

分类页文案原来是人工写的，写不动。我给他们搭了一条流水线：读一份产品线与应用场景的映射表，加上后台的规格字段，生成分类页的导语、选购要点，顺手按映射关系给每页配上相关分类的内链。

跑起来之后确实好用。每天出十来个页面的更新，文案不算惊艳但绝对合格，内链结构比人工时期整齐得多。头两周我天天看，每一条都对。第三周我改成隔天看，第四周改成每周扫一眼。

然后我做了那个最要命的判断：这套东西已经成了，可以当资产了。

回头看，这句话本身就是走形的起点。资产是不用盯的，系统是要盯的。我把一个系统当成了资产。

第五周我自己动了一次那张表，然后呢？

第五周客户上了两条新产品线，喷灌配件和修枝工具。我在那份映射表里加了两行，顺手把几个应用场景的归属调了一下。

加完我就去干别的了。这个动作在我当时的认知里，是一次内容维护，不是一次系统变更。

而流水线那边读的还是旧的那一版——具体说，是它缓存下来的一份副本，而缓存的刷新条件我当初写的是文件不存在时才重新拉。文件当然存在，所以它就一直没拉。

这个bug低级得让人不好意思写出来。但它的表现一点也不低级：流水线没有报错，没有产出异常，没有跳过任何一步。它只是继续拿一份旧地图，认真地干着活。

三个月里，为什么没有一个信号提醒我？

接下来八个星期，它给九个新分类页生成了文案。因为旧表里没有喷灌配件这条线，它就按最近似的匹配处理了——给喷灌配件套用了浇水器具的文案，给修枝工具套用了园艺剪的文案。

写出来的东西通顺、专业、有细节。只有一个问题：里头提到的型号和适用范围，客户不卖。

我当时手上有的所有信号，逐个说：

最后一行是我最该反省的。六十多个分类页里抽三五个，抽中那九页的概率本来就低，而且哪怕抽中了，我看的时候也未必看得出来——那些文案本身没有任何毛病，要发现问题，我得同时知道客户到底卖不卖那个型号。

最后是销售的一句吐槽把它揪出来的？

第十三周，客户那边负责询盘的销售在周会上抱怨了一句。原话大意是，最近来问的客户，问的老是我们不做的那个型号。

他不是在报bug，他是在吐槽线索质量差。

我当时的第一反应也不是查流水线，是想是不是投放的词买错了。查了两天广告端，词没问题。第三天我才顺着落地页往上摸，摸到那九个分类页。

我在这里插一句给做站的同行：你那套自动化系统真正的报警器，很可能长在销售和客服的嘴上，而不是长在任何一块看板上。这也是客服和SEO那份七动作协作账本值钱的地方，它把这条人肉信号变成了固定流程。

问题是这条通路极慢。销售要攒够足够多的怪事才会觉得值得说一句，而这个门槛差不多就是两个月。

修的时候我才发现，问题不在流水线的逻辑？

找到之后我先去看生成逻辑，想找出是哪一步匹配错了。看了半天，逻辑是对的。

它读的表里没有喷灌配件，它按相似度找了最近的一条，这个行为完全符合我当初的设计——我甚至在提示词里明确写过找不到精确匹配时用最接近的类别。

所以这套东西从头到尾都在正确地执行我的指令。它唯一不知道的事情是：它手上那份表已经不是最新的了。

而它没法知道，因为那份表从来没有告诉过任何人自己是第几版。它没有版本号，没有变更记录，改动前后文件名都一样。

这就是我说走形必然是静默的原因。一个不能声明自己版本的输入源，配上一个不会怀疑输入的执行器，中间那段偏差在结构上就是不可观测的。这跟模型强不强、提示词写得好不好，一点关系都没有。

影响面为什么比我最初估的宽一倍？

我一开始以为要修九页。实际上是四十多页。

因为内链是按同一份映射表配的。旧表里没有那两条新产品线，所以：

• 九个新分类页的相关分类，指向的全是不相干的邻居
• 原有的分类页里，一个都没有指向这两条新线
• 这两条新线在站内结构上等于孤岛，靠站点地图挂着，没有任何上下文链接

换句话说，同一个走形源头同时污染了内容层和链接层。这也解释了为什么客户当时新上的两条产品线迟迟起不来——不是内容不够，是站内没人给它们引路。

这一层容易被误当成长期无人打理造成的自然腐化，其实成因完全不同：我这个是一次输入源过期在一夜之间造出来的，表现却很像。所以看到内链结构不对时，先问一句它是不是某个自动化产出的——是的话，去查那份配它的表，别去查链接。

还有个细节值得记：这套流水线的代码从头到尾没出过毛病。这跟氛围编程做出来的工具三个月后没人敢动那篇讲的困境不是一回事——那篇担心的是代码烂到没人敢改，我这次是代码干净、逻辑正确、谁都能读懂，它照样把活干错了。代码质量和产出正确是两个独立的维度，前者归工程，后者归输入。

我后来补了哪三件事？

修那四十多页花了三天，改流程花的时间比修页面长。我最后只加了三件事，都很土。

1. 映射表顶部两行：版本号和最后修改日期。流水线每次运行把这两行抄进产出日志，版本号变了就停下等我确认一次
2. 缓存刷新条件改掉：从文件不存在时拉，改成修改时间变了就拉。这一行代码是这三件事里技术含量最低、收益最高的
3. 找不到匹配就报警，不许近似：把提示词里那句用最接近的类别删了，改成找不到精确匹配就跳过并记一条待办。宁可少产出，不要产出得体面而错误

第三件事的改动最反直觉。当初写那句近似匹配，是为了让流水线不要因为小问题停摆，听着很稳健。实际上它把一个会自己喊停的系统，改造成了一个会自己编答案的系统。

这里我得说清归因：那两条产品线后来起来了，但同期客户也补了实拍图和规格表，还清了一批停产型号页。所以恢复不能全算在这套流程的账上。这三件事真正保证的是下次不会再静默三个月，这才是它的价值。

这次失手让我改掉了哪个习惯？

最大的收获不是那三条改动，是我改掉了一个说法。

我以前会说这套自动化做完了。现在我说它在跑。

听着像文字游戏，但它决定了两件事：做完的东西进档案夹，在跑的东西进日程表。我现在给每套还在跑的自动化都留了一个固定的周检时段，不管它上周表现多好。

还有一条个人层面的：凡是我自己手改过的东西，都要主动去想一遍谁在读它。第五周那次我改的是一份表格，在我脑子里那是内容工作。实际上我当时是在给一台正在运转的机器换零件，而我没有通知那台机器。

顺便说，这类失手在去技能化陷阱那篇讲的是另一半问题：那篇担心的是活全交给AI之后人的判断力退化，我这次栽的是判断力还在、但系统状态我不掌握。两件事都会让你在关键时刻使不上劲，路径完全不同——一个是人退化了，一个是人没退化但信息断了。

四周把一套系统守住，该按什么顺序排？

可以直接照搬的路径，有个反直觉的地方：前两周一行代码都不写。末尾附只做一件事的极简版。

第一周该清点什么，为什么不能从搭东西开始？

下面这条四周路径，是我在那次失手之后整理出来的，园艺工具站的第二套流水线就是照这个顺序上的。它有一个反直觉的地方：前两周一行代码都不写。

第一周只做清点，产出是两份清单。

第一份是正在跑的东西：所有定时任务、所有还开着的自动化、所有你以为已经关掉的实验。列的时候按路径列，不按功能列，因为功能名会骗你。我那次清出来三个早该关掉的任务，其中一个还在往一张没人看的表里写数据。

第二份是被读的东西：每个流程读哪些文件、哪些表、哪些接口。这份清单的价值在于它会暴露共读——同一份表被三个流程读，那它就是全站最危险的单点。

清点听着无聊，但这是整条路径里唯一一次能把系统边界看全的机会。

第二周为什么该先上版本，再谈别的？

第二周做两件事，都是给上周清出来的东西补身份。

一是给每份被读的输入源加版本号和修改日期，并让读它的流程把这两个值记进产出日志。二是把每套自动化写一段五行以内的说明，讲清它读什么、产出什么、多久跑一次、谁能改它。

五行是硬限制。写长了没人看，写长了你自己下次也不会更新。

为什么这一步必须排在第二周，而不是等系统搭完再补？因为补文档这件事一旦挪到后面，就永远排不上。而更实际的原因是：版本号只有在你还记得当前状态时才写得准，隔一个月再补，你写的就是猜测。

这两件事加起来大概一天。它是整条路径里性价比最高的一天。

第三周该给系统装哪几个探针？

第三周才动手，装的是前面说的那种意外通知。三个探针，按实现难度从低到高。

1. 版本变更探针：输入源的版本号或修改时间变了，跑之前先停下通知你。实现就是比两个值
2. 形状偏离探针：本次产出的条数、平均长度、字段填充率，跟上一次比偏离超过设定的幅度就告警。实现是存一份上次的统计
3. 新值探针：关键字段里出现了基线枚举之外的取值就告警。实现是维护一份允许值列表

三个探针都不判断对错，它们只判断变化。这一点必须想清楚：让机器判断对错很难，让机器判断变没变很容易，而走形的特征恰好是变化。

我那次的九个页面，第三个探针一秒就能抓到——喷灌配件是一个新值，旧表里没有。可惜当时没有这个探针。

第四周该定的是节奏还是文档？

两个都要，但排序有讲究：先定节奏，再补文档。

节奏就是把前面那张十四项体检表落进日程。每周那四项挑一个固定时段，比如周一上午的头二十分钟；每月那五项挂在月初；每季那五项挂在季度第一周。挂进日历，不要挂在决心里。

文档只补一份，叫交接页。内容是：这套东西现在读哪些源、按什么顺序跑、上次改了什么、如果全塌了从哪开始重搭。一页纸，随改随更。

为什么节奏在前？文档会因为没人看而腐烂，节奏不会——它每周提醒你一次，顺手就把文档更新了。反过来先补文档，你会得到一份写得漂亮、三个月后完全失效的东西。

这四周的顺序为什么不能颠倒？

有人会想，探针最有用，为什么不第一周就装。

因为探针需要知道盯什么。你没清点，就不知道有哪些输入源该盯；你没上版本，版本变更探针压根没有可比的值；你没有基线枚举，新值探针也不知道什么叫新。

顺序反过来的典型后果是：装了一堆告警，跑三天全是噪音，你把通知关了。这个坑我见过不止一次，而且关通知的那个动作通常发生在第四天，之后再也没打开。

所以这条路径的真实逻辑是：前两周是在给探针造可比的对象，第三周才是装探针，第四周是让它活下来。少任何一段，后面那段都会失效。

一个人做和有团队做，差在哪一步？

四周路径本身不分人数，差别在第四周那份交接页。

一个人做的时候，交接页的读者是三个月后的你自己。这个读者比你想的更陌生——研究里那位翻找边界文件的参与者，翻的就是自己的系统。

有团队的时候，交接页要多一栏：谁有权改它。这一栏不写清楚，你会遇到那种最难查的走形：两个人先后改了同一份表，各自觉得对方知道。

还有一个只在小团队出现的问题：那套自动化通常只有搭它的人敢碰，于是它变成了那个人的私产。这不是态度问题，是状态没有外化。那套四层AI运营架构讲的是怎么把一个人的本事变成团队的标准动作，本文补的是它的运行期一半：标准动作定下来之后，还得有人盯着它有没有走形。

园艺工具站第二套流水线，实际跑成什么样？

同一个客户，第二套流水线做的是产品页的规格摘要和常见问题块，比第一套更敏感——它直接碰事实。

照这四周上，实际情况和计划有两处偏差，值得说。

第一处：清点第一周就发现规格字段的填充率只有六成多，而不是我以为的九成。这意味着流水线有近四成的产出是在缺料的情况下生成的。这个发现直接改变了项目优先级——先补料，再上自动化。清点最大的收益经常不是清出了什么任务，是清出了输入源本身不够用。

第二处：新值探针第一个月误报很多，因为规格里的单位写法不统一，同一个意思有四五种写法。我一开始想放宽阈值，后来改成先把单位写法统一了。误报是在替你指路，别急着把它调低。

这套跑到现在没出过静默走形，抓到过两次版本变更告警，都是客户那边改了规格表没通知我。

如果只能做一件事，该做哪一件？

四周听起来不长，但很多人连第一周都排不出来。所以给个只做一件事的版本。

做输入源的修改时间检查。就一条：把所有被自动化读取的文件列出来，每周看一眼它们的最后修改时间，有变化的就去确认下游知不知道。

为什么是这一条？因为它盖住了最常见的那个走形源头，成本是每周三分钟，而且不需要任何工具、不需要改代码、不需要别人配合。

我那次三个月的静默，只需要这一条就能在第六周被抓到。一个每周三分钟的动作，当时能省下我三天的返工和客户两个月的错误线索。这笔账我算过之后，就没再跳过它。

产品教不会他们，那你的网站教得会客户吗？

这里把镜头转过来。研究者抱怨厂商没做好上手入口，而对你的客户来说，你就是那个厂商。

为什么这些工具自己教不会你用它？

研究里有个结论我觉得被低估了：七位参与者无一例外，都表示这些AI编程产品本身当不了学习来源，跟他们技术水平高低无关。

原因研究者也给了：这类系统天生不透明、表现不均匀，而你要撞上它的边界才能看见边界。哪怕用的是同一家实验室的产品，不同模型的行为也不一样，擅长的活也不一样。

再往下还有一层：编排型智能体管着子智能体，表现好不好取决于你在建什么；token烧得多还是少，取决于系统怎么搭。这些都不是能写进说明书的常量，它们是你这套系统的函数。

所以说明书写不出来，不是因为厂商懒。是因为答案依赖于你的场景，而厂商不知道你的场景。这句话待会儿会反过来砸到我们自己头上。

那七个人到底从哪儿学的？

答案是从人那儿学的。少数人靠朋友、伴侣、同事，多数人靠线上社区——推特、Reddit、油管、Slack群。

其中一位把自己的主要学习渠道说得很具体：推特和Reddit，某个大号发一条，回复里就有五六个不同的替代方案。

值得停一下的是这位是谁：他跑着整个样本里技术上最复杂的一套系统，八个以上的工具、自动化编排、一队起了名字的智能体。而他的主要知识来源是社交媒体。

这个组合听着别扭，其实很好理解：说明书讲功能，社区讲搭配，而搭建这件事九成的难度在搭配上。

没有上手入口这件事，为什么是致命的？

研究里那几句原话读起来挺扎心。有参与者说自己压根不明白那个面向普通信息工作者的产品是干什么用的，也说没有任何新手引导，就算去问模型本身，也得不到什么时候该用哪个的清楚指引。

还有一位重度使用者，在定时任务的界面里彻底迷失了方向，他说自己都不知道现在身在何处——在某个项目的某次定时运行的某个对话格式里，可这到底是哪儿。

这里有个反差值得记下来：这些工具的能力已经远远超过了它们的可上手性。研究者最后的判断也是这个——光有能力赢不下这个市场，缺的是一个能用的入口。

顺便说一句，那个面向普通信息工作者的产品到底怎么定位、和终端里那个工具怎么分工，Claude Cowork那篇深度解读把这两者的边界讲清楚了。研究里参与者的困惑，某种程度上正说明这件事需要有人专门讲一遍。

默会知识为什么只能靠人传人？

研究的结论落在一个挺老的概念上：这就是隐性经验一直以来的传播方式——靠观察、靠共同实践、靠花时间真的去做。

研究者说不寻常的地方在于，这件事发生在一项本该直觉到不需要学徒制的技术上。对话式系统的承诺一直是任何人靠聊天就能用起来，至少现在看，不是这样。

他们还用了一个我很喜欢的比喻。学新东西通常像看一扇起雾的窗户，雾慢慢散开。智能体这套东西不一样，它像在片状的雾里走——某些区域短暂地清晰起来，其他地方仍然模糊。你对地形的感觉在变好，但永远得不到一张完整稳定的图。而正当一处雾散开，实验室发一个新模型，地形又变了。

这个比喻对做内容的人有直接价值：你的读者不是在寻找一张完整的地图，他们是在寻找下一步能踩哪儿。这两种需求要的内容形态完全不同。

现在把镜头转过来，谁是别人的厂商？

前面这四节我都在讲那七个人的困境：产品不教他们，文档帮不上，只能去社区扒。

现在换个角度。你的网站，正是别人的那个厂商。

你的产品页、规格表、帮助中心、安装说明、兼容性列表，对一个正在做选型的非专家来说，就是他手上唯一的入口。而他会不会用你的东西，很大程度上取决于这个入口好不好进——不是取决于你的产品有多强。

这一跳是我认为整篇最值钱的一跳。研究者抱怨厂商没有做好上手入口，这个抱怨对我们不是一条行业观察，是一份镜子。我们抱怨的那件事，我们自己正在对客户做。

而且做站的人还多一层劣势：厂商至少有客户成功团队能补，你只有那几个页面。

那批非专家买家，为什么正在快速变多？

这不是个小众趋势。押注非开发者是下一个主要市场，这件事已经从假设变成了产品策略。

研究做完之后没几天，OpenAI把Codex从开发者的编辑器里挪了出来，上了六个面向具体岗位的插件，覆盖销售、创意生产、公开股权投资这些角色，接下来点名的还有企业财务、营销策略和战略咨询。按OpenAI自己给的数字，知识工作者已经占到Codex每周五百万活跃用户的约五分之一，增长速度是开发者的三倍多。

把这几个数字翻译成生意：非技术岗位的人正在成批地获得直接搭系统的能力，而他们采购工具、资料和供应商的方式，就是研究里那七位学东西的方式——看社区、看别人的实操、看能不能照着做一遍。

如果你的客户里有采购、有工程、有实验室、有运维，那这批人就是你未来两年的询盘来源。他们不会先读你的公司简介。

你的规格表，为什么就是别人的上手材料？

具体说说这批人怎么看你的站。

他们的行为特征和研究里那七位高度一致：先找一个能照着做一遍的东西，中间卡住就去搜一句具体的话，搜不到就换供应商。他们不看宣传语，也不太在意品牌故事，因为他们此刻的任务不是相信你，是把手上那件事干完。

对应到页面上，能帮到他们的东西非常朴素：

• 完整的参数表，包括那些不好看的限制条件和不适用场景
• 兼容性和搭配清单，说清跟什么能配、跟什么不能配
• 一步一步的操作说明，带上会卡住的那几步
• 明确的失败条件：什么情况下这东西不适合你

最后一条最反销售直觉，也最管用。研究里那些人之所以信社区不信官方，就是因为社区会告诉你什么不行。

能被非专家一次读懂的页面，为什么才会被反复引用？

最后把这条接到可见度上。

替这批人做检索的，越来越多是模型。而模型在挑引用对象时，偏好的东西和非专家读者偏好的东西高度重合：自足、具体、带条件、能直接答一个问题。一段需要读者自己补三条背景才能懂的文字，模型也没法拿来当答案。

所以可上手性和可引用性在这里合成了一件事。你为那个卡在第三步的采购写清楚的那一段，恰好也是模型最容易摘走的那一段。

这条的具体做法不在本文范围。要把内容按机器读得懂的方式组织，机器优先架构那份重构清单讲的是结构层；要让答案能被摘走，四阶段GEO流水线讲的是从摘要到重写怎么走。本文只补一个判断依据：写完一段，问一句非专家能照着做吗。答不上来，模型大概也摘不走。

这套判断最容易被误读成什么？

最后堵掉六个常见的误读，顺便把该有的心态和本周就能动手的三件事说清楚。

误读一：那结论是不是别自动化了？

接下来把几个常见的误读挨个堵掉，因为这套判断很容易被听成保守派发言。

不是。这篇从头到尾没有一句劝你退回手工。

真正的主张是：自动化的成本不在搭建，在维持。而大多数人只给搭建做了预算，没给维持做预算。于是每套系统都活得像个一次性项目，跑到走形为止。

要划的边界不是能不能自动化，是哪些活自动化之后值得配一套维持机制。这个判断哪些活该交出去的部分，SEO自动化的边界那篇已经分得很细，可以配着看。

误读二：加一道人工审核不就行了？

这是最常见的一条，也是最像解决方案的一条。

人工审核对准入有效，对走形基本无效。原因前面说过：走形期的产出通顺、格式对、逻辑自洽，审核的人要发现问题，得同时掌握正确答案。

而正确答案在哪？在那份被改过的输入源里。所以审核的人真正需要的不是审核时间，是知道输入源换过版本。给他一条版本变更通知，比给他两小时审核时间管用得多。

顺便说，人工节点该往哪放这件事本身有讲究，AI内容流水线那三处人工节点是按内容质量与合规风险来定位的，属于每篇都要过的闸；本文讲的是每周对系统本身做的体检。前者防的是单篇不合格，后者防的是整批悄悄偏了，两道闸拦的不是一回事。

误读三：换个更强的模型能不能解决？

不能，而且换模型本身就是走形的第五个源头。

模型变强改善的是单次产出质量。走形的成因是输入源过期、规则被改、上下文塞满、连接失效，这四样跟模型能力一点关系没有。一个更聪明的执行器拿着一份过期的地图，只会把错误方向走得更远、更有说服力。

换代还会带来新问题：同一段提示词在新模型下的解读变了，输出的详略、口吻、结构跟着变，你原来那套判断标准会失准一段时间。

所以模型升级应该按变更处理，走一遍基线重测。基准刷新之后哪些活能交给智能体那篇讲的是能力边界随基准怎么动，本文补的是每次动完你都得重新验一次自己的活。

误读四：文档写好了是不是就不会走形？

文档解决的是别人看不懂，不解决状态不同步。

这两件事经常被混为一谈。你可以有一份写得非常清楚的文档，同时那套系统正在读一份三周前的表——文档描述的是设计，走形发生在运行。

研究里那个边界文件的故事就是最好的反例：那份文件存在，内容也是规则，问题在于它是系统自己维护的，且当事人不知道里面写了什么。文档的存在没有带来任何掌控。

所以顺序是：先让状态可观测，再让状态可读。版本号是状态，文档是解释；没有状态的文档，是一篇散文。

误读五：这是不是大团队才有的问题？

正好相反，一个人的时候最严重。

团队里有一件事天然帮你：别人会问。有人接手、有人复用、有人在群里问一句这个数怎么来的，这些都是免费的走形探测器。一个人干活的时候，这些全没有。

研究里那七位大多是在企业内部搭系统的，即便如此他们也报告了衰败和跑偏。独立站主的处境更极端：没有人会问你，而你的产出直接对外。

所以那份体检表对一个人的场景不是可选项，它是替代同事的那套东西。你得自己扮演那个会问一句的人。

误读六：抽查加大力度是不是就够了？

抽查的问题不在力度，在数学。

假设六十页里有九页错了，你抽五页，一页都没抽中的概率不算低。而且哪怕抽中一页，你也得恰好知道那个型号客户不卖，才看得出来。两个条件要同时满足。

把抽查量翻三倍，成本翻三倍，命中率提升有限。而查输入源版本这件事，是查一个只有五六项的短名单，成本几乎不变，命中率接近百分之百。

这就是我说所有资源都该压在缩短发现时间上的意思。抽查是在错误堆里找错误，查版本是在源头等着它。同样的钱，后者的杠杆高一个量级。

那正确的心态到底是什么？

说句实在的：把你搭的每套自动化都当成一个刚入职的实习生，不是当成一台买回来的机器。

实习生干活能干，也真能帮你省时间，但你会每周看看他做得怎么样，会告诉他哪些事必须先问，会在他手上的资料变了时通知他一声。你不会因为他上个月表现好，就三个月不看他的产出。

机器不需要这些，所以人们习惯用对机器的方式对待这套东西——装好，验收，然后忘掉。这个心智模型是所有静默走形的根源。

研究里那句话现在可以完整地读了：它可能是座纸牌屋，但仍然是座有用的纸牌屋。既然是纸牌屋，就得知道风从哪边来。

从这周开始，先做哪三件事？

不用等排出四周，这周就能做三件，加起来不到一小时。

1. 列出所有被自动化读取的文件，看一眼各自的最后修改时间。这一件事就能盖住最常见的走形源头
2. 确认规则文件不是系统自己在改。如果是，立刻把它挪到系统拿不到写权限的路径下，改由你自己维护
3. 给最重要的那份输入源加两行：版本号，最后修改日期。然后让读它的流程把这两行记进日志

三件事都不需要新工具，不需要预算，不需要说服任何人。它们的共同点是把不可观测的东西变成可观测的。

保哥这些年在AI这块交的学费，绝大部分不是买错了工具，是把在跑的东西当成了做完的东西。这句话要是能替你省下一次三个月的静默，这篇就算值了。

常见问题解答

我就几个脚本加一张表，这也算一套系统吗？

算。判断标准不是规模，是有没有状态：它读的东西会变吗，它的产出会不会被别的环节接着用。两个都有，它就有状态，就会走形。

反过来说，一个每次都从零开始、读的东西你每次都亲手给它、产出你当场就看完的用法，那不叫系统，那叫用工具。这种用法几乎不会走形，也不需要本文这套东西。分界线就在有没有留在那儿等下次的东西。

走形和内容老化、内链衰减是一回事吗？

不是，三者的成因和查法都不同。内容老化是外部世界变了、你的页面没跟上；内链衰减是长期改版和跳转累积造成的结构腐化，没有AI参与。

走形的特征是系统本身没变、指令也没变，变的是它读的输入。所以前两者靠爬站和看搜索结果能查出来，走形只能靠回溯输入源的版本。三样可能同时发生在一个站上，别把它们混成一个待办。

给输入源加版本号，具体怎么加，要用什么工具？

不用工具。在表格或配置文件顶部加两行纯文本就够：一行版本号，一行最后修改日期。改一次内容就把版本号加一，日期跟着更。

关键是第二步：让读它的流程把这两个值抄进产出日志，并且在版本号变化时先停一次等你确认。停这一下通常花你半分钟，它换来的是往后每一批产出都能回答当时读的是哪一版。有版本控制的话直接用提交记录更好，但没有也照样能做。

已经静默跑了几个月，怀疑出过问题，该从哪儿查？

不要从页面查，从输入源查。把所有被读取的文件按最后修改时间排一遍，找出那些修改时间落在这几个月中间的。每一个都是一次可能的走形起点。

找到时间点之后，去看那个时间点之后产出的那批东西，重点看事实类字段：型号、规格、价格、适用范围、分类归属。这个顺序能把排查范围从全站几百页压到几十页。反过来先翻页面，你会翻很久还翻不出规律。

自动模式和逐次确认，到底该开哪个？

先写死路径级的拒绝规则，再开自动模式。这个顺序不能反。

逐次确认的问题是它会被点成肌肉记忆，寿命撑不过一两周；自动模式的问题是什么算危险由工具的通用判断决定，而它不知道你站里改一行抓取指令比删十个文件严重。两个各有短板，补法是同一个：把你自己那份绝不能写的路径清单先变成硬规则，剩下的交给自动模式。

就我一个人做站，那十四项能砍到几项？

砍到一项都行，前提是砍对那一项。留输入源的修改时间检查，每周三分钟，它盖住的是最常见也最难发现的那类走形。

再有余力就加第二项：关键字段里出现基线之外的新取值就停下确认。这两项加起来每周不到十分钟，能拦掉我见过的大部分静默事故。剩下十二项是给系统变多、有人接手、开始碰事实类字段之后准备的，那时候再往上加。

权威参考资料