【AI Coding】10-AI只找得到有什么看不见用户看到什么验收盲区的病理与补法AI 只找得到有什么看不见用户看到什么验收盲区的病理与补法一、测试用例全对用户体验极差二、病理AI 的工作循环封闭在代码空间三、补法不用发明四份现成方法一个共同动作3.1 Gherkin Given/When/Then把验收基准搬进观察空间3.2 认知走查法站在新用户的座位上每步四问3.3 用户旅程图给病根命名3.4 User Story Mapping时序是骨架功能是肉四、三步验收流水线建表、走查、模拟4.1 第一步每条用例配一张操作时序表4.2 第二步按时序逐行五问走查4.3 第三步模拟用户在模拟器上真走一遍4.4 组装批次验收公式与三条纪律五、结论测试绿、用户能用、承诺兑现是三件事参考资料AI 只找得到有什么看不见用户看到什么验收盲区的病理与补法这一篇处理 AI Coding 里最隐蔽的一类翻车功能做完了测试全绿用户上手却走不通。结论先说这是 AI 视角的结构性缺陷补法是把用户看到的东西物化成 AI 能读的文档落地为建表、走查、模拟三步。一、测试用例全对用户体验极差过去一段时间我们用 AI Coding 开发了一款时间管理应用 know-u-time想到的事记下来AI 拆成步骤按截止日倒推开始时间到点提醒。产品唯一的用户是我们自己每天装在手机上真机使用。开发过程出乎意料地顺倒排引擎、红黄绿状态灯、提醒预算功能一批批上线测试从零涨到两百多xin个。最近一轮改动收尾246 个测试全部通过静态检查零告警。无论按哪条工程标准这都是一次可以放心的交付。问题出在装上手机之后对 AI 助手说了一句要记的事它回复已记录转身去事项页找结果这条记录根本不存在。拆开看解析逻辑在AI 说话的通路在拦着 AI 直接写数据库的闸门也在。每一块单看都是好的测试也确实是绿的。断掉的是用户那条说话看到’已记录’去事项页找到它的路。这不是孤例。把 know-u-time 上线以来历次真机使用的问题记录全部摊开回看没有一条是功能坏了报错全部落在四类规律判据实证全部真机抓出且当轮测试全绿① 能力不可见功能在用户不知道/找不到/想不起AI 整理一遍藏在随手做区头部② 反馈与事实不符话术说 X实际做了 Y已记录实际没落库安静时段副标写死与实现不符③ 语义差一层词对但不是用户心智里的意思再改改实为放弃记下对目标型只给单步④ 观感不一致同物不同处长相不一样布局被撑破三处输入条三种观感长标签挤爆分段控件四条规律背后是同一个深层结构时序断裂。用户不逐个功能地生活用户沿一条时间线走想做一件事做一个动作看到反馈决定下一步。逐点检查每个功能都在抓不住用户那条路走不通。翻译成时序视角四条规律各有各的断法规律时序视角的判读① 能力不可见断头入口不在用户的路线上走到那一步也不会路过它② 反馈失真顺序颠倒“宣布结果先于落库”或根本没有落库步③ 语义差一层分支标错用户以为回到上一步系统当成流程结束④ 观感不一同一步骤从不同时序入口进入时长相不一样测试抓不住它们原因藏在 AI 的工作循环里。二、病理AI 的工作循环封闭在代码空间AI Coding 的工作循环是检索代码修改代码运行测试读测试输出再改。这个循环里AI 能第一时间感知的一切都在代码空间即文件、函数、调用链、测试断言、编译输出构成的那个世界。它的行动工具grep、跑测试也全部作用在这个空间。观察空间指用户的感知面包括屏幕上出现了什么、文案说了什么、点了之后哪里变了、下一步入口在哪。AI 对这个空间没有直接感知通道只能读渲染代码和文案常量去推断。它永远在找有什么从未看到用户看到什么。三个机制把这个盲区固定下来感知不对称。AI 对代码空间有直接感知对观察空间只有间接推断。断言同源。写测试的也是 AI它顺手断言自己最方便感知的内部状态等于让被告写证人证词。逐点对时序。AI 的检索是逐点的找函数、找入口、找配置。四条规律全是时序的逐点检查在结构上抓不到顺序问题。第二点有现成证据。我在这次翻车里犯的错正是让测试断言记录已写入数据库。Cucumber行为驱动开发测试框架的 Gherkin 场景文档里有一条几乎为此刻准备的红线Then 要断言从系统里出来的东西报告、界面、消息文档原话“While it might be tempting to implement Then steps to look in the database - resist that temptation!”理由文档也说得很直白数据库的变化通常用户和外部系统根本观察不到。断言内部状态的测试哪怕全绿也只证明机器记得不证明用户看得到。已记录但没落库在这类测试上永远现不了形因为测试和缺陷说的是同一句假话。所以换个更强的模型没有用多写几条规则也没有用。AI 的工作循环封闭在代码空间一天这个盲区就是结构性的。补法是给验收环节开一个观察空间的洞。这个洞不用发明新工具去挖可用性工程几十年积累的方法恰好都能用上。三、补法不用发明四份现成方法一个共同动作四份方法出自三个来源Cucumber、NN/g、Jeff Patton抽象层级相差很大小到一行断言的写法大到整张需求地图的组织方式。共享的动作只有一个把用户在观察空间里的路线写成文档。写下来AI 才有得读有得读验收才有得对质。3.1 Gherkin Given/When/Then把验收基准搬进观察空间BDDCucumber 官方文档的场景三段式Given 铺用户所处的情境When 写用户的动作Then 写用户可观察的结果就是上面那条红线。对 AI Coding 的价值一张 Gherkin 风格的时序表每一行都在逼作者回答用户做完这个动作屏幕上会多出什么。“已记录但没落库在这张表上自动现形Then 列写用户看到’已记录’”事实列却是空的。两列一对质缺陷无处藏。3.2 认知走查法站在新用户的座位上每步四问NN/g 的认知走查法对时序里的每一步问四个问题用户会想做这件事吗看得到正确的操作入口吗能把入口和他的目标对上号吗做完能看到进展了吗任何一问答否这一步判失败。第④问是 AI 最容易漏的一问。AI 改完代码会确认动作被处理了代码空间很少追问界面上有没有任何可观察的变化观察空间。这次翻车漏的就是第④问。前三问专抓功能在但用户走不通入口看不见对应规律①名字对不上心智对应规律③。3.3 用户旅程图给病根命名NN/g 的旅程图是比验收更上游的设计工具要素包括 actor、场景、阶段、每阶段的动作想法情绪、机会点。它解决的核心问题NN/g 的命名是碎片化理解每个角色只盯着自己那段的指标没有人拥有完整体验。这个诊断移植到 AI Coding 上严丝合缝。AI 是碎片化理解的极端形态每次只被喂一段上下文只对当前改动的模块负责没有任何一个时刻它拥有完整体验。用户旅程的连续性在 AI 工作流里没有天然的拥有者所以必须写成文档、变成显式资产不能指望工作流里自然涌现。3.4 User Story Mapping时序是骨架功能是肉Jeff Patton 的用户故事地图回答时序从哪来需求不按功能列表组织先画用户活动到步骤的骨干功能挂在这条骨干上。落到需求文档的写法先有时序再有功能把功能列表重挂到用户一次会话的动作流上。功能列表是 AI 最习惯的需求格式好检索、好逐点实现也正是它让用户那条路在文档里消失了。四、三步验收流水线建表、走查、模拟方法落进工程固化成项目仓库 know-u-life 里的两个 Skill也就是本系列第 1 篇定义的那种工程技能文件acceptance管验收user-sim管模拟用户走查。核心动作只有一个把 AI 看不见的东西全部物化成 AI 能读的文档再让 AI 沿文档走查。4.1 第一步每条用例配一张操作时序表每条用例UC的验收基准不只写功能存在再补一张五列表#用户动作When系统做什么事实用户看到什么Then可观察输出之后能从哪继续出口1对助手说了一句要记的事无任何写库动作气泡回复已记录去事项页找到这条记录这一行不是假设它就是开头那次翻车在表上的样子。Then 列承诺了已记录事实列是空的出口列指向的事项页里没有这条记录。三列一对质缺陷自己现形。填表守四条纪律事实列只写系统真实行为落了哪张表、发了什么、改了什么状态。Then 列只断言可观察输出气泡文案、卡片、列表项、计数。“存进 DB”标记 flag不进此列。每行出口必须真实存在UI 里点得到。出口列是规律①的定向探针。感知不得超出事实Then 列比事实列说得多即缺陷。没有时序表的老用例先按五列补表十分钟级。表本身经常就是发现源写不出出口列就是规律①Then 与事实对不上就是规律②。4.2 第二步按时序逐行五问走查对时序表逐行走每行五问。前四问借自认知走查法第五问是 Gherkin 红线与四条规律的合流问抓什么判定为问题的标准① 用户会想做这步吗时序违背目标顺序要求用户先做不关心的决定② 看得到入口吗能力不可见控件不在上一行的出口列里或藏条件后③ 入口能对上号吗语义差一层名字让用户预期 A实际触发 B④ 做完看到进展了吗反馈缺失动作成功后界面无可观察变化⑤ 感知不超过事实吗反馈失真Then 列承诺的多于事实列做的五问里前三问抓路通不通后两问抓话真不真。规律④观感不一致在纸面上现不了形留给第三步。4.3 第三步模拟用户在模拟器上真走一遍文档对质抓纸面矛盾。渲染变形、点击无响应这类只存在于运行时的问题需要在观察空间采样把走查交给一个模拟器 Agent时序表即剧本每行翻译成一条指令做 When 列动作断言 Then 列可观察输出验证出口列可达。模拟用户从找功能变成照用户路线走。边界要说清模拟用户抓不全规律①②。它本来就在找功能不知道能力存在却看不见算问题它没有事实可对照判断不了话术是否失真。这两类只能靠时序表过筛抓。文档走查与模拟走查互补不互替。4.4 组装批次验收公式与三条纪律三步再配上承诺核对组装成每个功能批次的验收公式批次验收 承诺核对当轮产品规格承诺逐条对源码 时序走查当轮 UC 时序表逐行五问 模拟会话一场剧本取自时序表三条纪律保证公式不空转评估者与生成者分离。先列承诺清单再找证据不许边读实现边顺便想想还有什么承诺。从未实现的承诺在代码里没有痕迹只在文档里。证据不足不算通过。没核到的项保持 UNVERIFIED。测试绿是验收的前置条件不构成验收。四规律回写。每条真机反馈先归类到四条规律之一修完必自问同类问题还藏在哪几个功能里然后全量过筛一次。实证一个功能批次246 个测试全绿当天时序走查仍查出已记录未落库和入口缺失两处缺陷。测试绿没有拦住它们时序走查拦住了。五、结论测试绿、用户能用、承诺兑现是三件事AI 改动经常有问题是结构性盲区不是能力缺陷。AI 的感知、行动、断言全部封闭在代码空间用户的四类高频问题全在观察空间且全是时序断裂。验收靠 AI 自己读代码写测试这个洞就补不上。补洞的原理是物化。时序表把用户路线写成资产五问走查把认知走查写成流程模拟会话把运行时观察采样进来。AI 依然没有眼睛但每一步验收都被要求对着用户看到什么的文档举证。三条红线值得直接写进每个项目的验收纪律。Then 只断言可观察输出忍住别查数据库Gherkin动作之后必须看到进展认知走查第④问时序是骨架功能是肉User Story Mapping。测试绿、用户能用、承诺兑现三者要分别验证。第一句验证代码按设计工作第二句验证设计按用户预期工作第三句验证文档没有虚报。AI 的默认工作循环只覆盖第一句。参考资料Cucumber. Gherkin ReferenceGiven/When/Then 与 “忍住别查数据库” 红线NN/g. Cognitive Walkthroughs四问走查法NN/g. Journey Mapping 101actor/场景/阶段/机会点碎片化理解病灶Jeff Patton.User Story Mapping: Discover the Whole Story, Build the Right Product. O’Reilly, 2014本文写作风格依据写作风格提炼论文 OpenAI/Anthropic 官网本文实践载体know-u-life 工程.agents/skills/acceptance三轨验收体系与.agents/skills/user-sim模拟用户走查本文属于「AI Coding」系列文章第 10 篇AI Coding 系列0-工程化视角理解AI Coding与LLM应用的上下文演化1-如何在真实项目中设计一套可落地的Skills体系2-从写了不用到精准触发Claude Code Skill 实战编写指南3-Multi-Agent 协同与边界从单 Skill 到多 Agent 的演进4-自动化发布从手动粘贴到脚本发布踩过的坑5-Pi Agent Harness一个极简终端编码Harness的解构6-Meta-Harness 与 Harness 生态当 Agent 框架本身变成可编排的7-上下文税AI 工作流膨胀的病理与治理8-治理先行Skill 筛选、评估与工作流治理闭环9-常见问题与处理11-功能各有各的账旅程没有总账需求与产品割裂的病理与补法当前文章本文 【AI Coding】10-AI只找得到“有什么”，看不见“用户看到什么”：验收盲区的病理与补法
【AI Coding】10-AI只找得到有什么看不见用户看到什么验收盲区的病理与补法AI 只找得到有什么看不见用户看到什么验收盲区的病理与补法一、测试用例全对用户体验极差二、病理AI 的工作循环封闭在代码空间三、补法不用发明四份现成方法一个共同动作3.1 Gherkin Given/When/Then把验收基准搬进观察空间3.2 认知走查法站在新用户的座位上每步四问3.3 用户旅程图给病根命名3.4 User Story Mapping时序是骨架功能是肉四、三步验收流水线建表、走查、模拟4.1 第一步每条用例配一张操作时序表4.2 第二步按时序逐行五问走查4.3 第三步模拟用户在模拟器上真走一遍4.4 组装批次验收公式与三条纪律五、结论测试绿、用户能用、承诺兑现是三件事参考资料AI 只找得到有什么看不见用户看到什么验收盲区的病理与补法这一篇处理 AI Coding 里最隐蔽的一类翻车功能做完了测试全绿用户上手却走不通。结论先说这是 AI 视角的结构性缺陷补法是把用户看到的东西物化成 AI 能读的文档落地为建表、走查、模拟三步。一、测试用例全对用户体验极差过去一段时间我们用 AI Coding 开发了一款时间管理应用 know-u-time想到的事记下来AI 拆成步骤按截止日倒推开始时间到点提醒。产品唯一的用户是我们自己每天装在手机上真机使用。开发过程出乎意料地顺倒排引擎、红黄绿状态灯、提醒预算功能一批批上线测试从零涨到两百多xin个。最近一轮改动收尾246 个测试全部通过静态检查零告警。无论按哪条工程标准这都是一次可以放心的交付。问题出在装上手机之后对 AI 助手说了一句要记的事它回复已记录转身去事项页找结果这条记录根本不存在。拆开看解析逻辑在AI 说话的通路在拦着 AI 直接写数据库的闸门也在。每一块单看都是好的测试也确实是绿的。断掉的是用户那条说话看到’已记录’去事项页找到它的路。这不是孤例。把 know-u-time 上线以来历次真机使用的问题记录全部摊开回看没有一条是功能坏了报错全部落在四类规律判据实证全部真机抓出且当轮测试全绿① 能力不可见功能在用户不知道/找不到/想不起AI 整理一遍藏在随手做区头部② 反馈与事实不符话术说 X实际做了 Y已记录实际没落库安静时段副标写死与实现不符③ 语义差一层词对但不是用户心智里的意思再改改实为放弃记下对目标型只给单步④ 观感不一致同物不同处长相不一样布局被撑破三处输入条三种观感长标签挤爆分段控件四条规律背后是同一个深层结构时序断裂。用户不逐个功能地生活用户沿一条时间线走想做一件事做一个动作看到反馈决定下一步。逐点检查每个功能都在抓不住用户那条路走不通。翻译成时序视角四条规律各有各的断法规律时序视角的判读① 能力不可见断头入口不在用户的路线上走到那一步也不会路过它② 反馈失真顺序颠倒“宣布结果先于落库”或根本没有落库步③ 语义差一层分支标错用户以为回到上一步系统当成流程结束④ 观感不一同一步骤从不同时序入口进入时长相不一样测试抓不住它们原因藏在 AI 的工作循环里。二、病理AI 的工作循环封闭在代码空间AI Coding 的工作循环是检索代码修改代码运行测试读测试输出再改。这个循环里AI 能第一时间感知的一切都在代码空间即文件、函数、调用链、测试断言、编译输出构成的那个世界。它的行动工具grep、跑测试也全部作用在这个空间。观察空间指用户的感知面包括屏幕上出现了什么、文案说了什么、点了之后哪里变了、下一步入口在哪。AI 对这个空间没有直接感知通道只能读渲染代码和文案常量去推断。它永远在找有什么从未看到用户看到什么。三个机制把这个盲区固定下来感知不对称。AI 对代码空间有直接感知对观察空间只有间接推断。断言同源。写测试的也是 AI它顺手断言自己最方便感知的内部状态等于让被告写证人证词。逐点对时序。AI 的检索是逐点的找函数、找入口、找配置。四条规律全是时序的逐点检查在结构上抓不到顺序问题。第二点有现成证据。我在这次翻车里犯的错正是让测试断言记录已写入数据库。Cucumber行为驱动开发测试框架的 Gherkin 场景文档里有一条几乎为此刻准备的红线Then 要断言从系统里出来的东西报告、界面、消息文档原话“While it might be tempting to implement Then steps to look in the database - resist that temptation!”理由文档也说得很直白数据库的变化通常用户和外部系统根本观察不到。断言内部状态的测试哪怕全绿也只证明机器记得不证明用户看得到。已记录但没落库在这类测试上永远现不了形因为测试和缺陷说的是同一句假话。所以换个更强的模型没有用多写几条规则也没有用。AI 的工作循环封闭在代码空间一天这个盲区就是结构性的。补法是给验收环节开一个观察空间的洞。这个洞不用发明新工具去挖可用性工程几十年积累的方法恰好都能用上。三、补法不用发明四份现成方法一个共同动作四份方法出自三个来源Cucumber、NN/g、Jeff Patton抽象层级相差很大小到一行断言的写法大到整张需求地图的组织方式。共享的动作只有一个把用户在观察空间里的路线写成文档。写下来AI 才有得读有得读验收才有得对质。3.1 Gherkin Given/When/Then把验收基准搬进观察空间BDDCucumber 官方文档的场景三段式Given 铺用户所处的情境When 写用户的动作Then 写用户可观察的结果就是上面那条红线。对 AI Coding 的价值一张 Gherkin 风格的时序表每一行都在逼作者回答用户做完这个动作屏幕上会多出什么。“已记录但没落库在这张表上自动现形Then 列写用户看到’已记录’”事实列却是空的。两列一对质缺陷无处藏。3.2 认知走查法站在新用户的座位上每步四问NN/g 的认知走查法对时序里的每一步问四个问题用户会想做这件事吗看得到正确的操作入口吗能把入口和他的目标对上号吗做完能看到进展了吗任何一问答否这一步判失败。第④问是 AI 最容易漏的一问。AI 改完代码会确认动作被处理了代码空间很少追问界面上有没有任何可观察的变化观察空间。这次翻车漏的就是第④问。前三问专抓功能在但用户走不通入口看不见对应规律①名字对不上心智对应规律③。3.3 用户旅程图给病根命名NN/g 的旅程图是比验收更上游的设计工具要素包括 actor、场景、阶段、每阶段的动作想法情绪、机会点。它解决的核心问题NN/g 的命名是碎片化理解每个角色只盯着自己那段的指标没有人拥有完整体验。这个诊断移植到 AI Coding 上严丝合缝。AI 是碎片化理解的极端形态每次只被喂一段上下文只对当前改动的模块负责没有任何一个时刻它拥有完整体验。用户旅程的连续性在 AI 工作流里没有天然的拥有者所以必须写成文档、变成显式资产不能指望工作流里自然涌现。3.4 User Story Mapping时序是骨架功能是肉Jeff Patton 的用户故事地图回答时序从哪来需求不按功能列表组织先画用户活动到步骤的骨干功能挂在这条骨干上。落到需求文档的写法先有时序再有功能把功能列表重挂到用户一次会话的动作流上。功能列表是 AI 最习惯的需求格式好检索、好逐点实现也正是它让用户那条路在文档里消失了。四、三步验收流水线建表、走查、模拟方法落进工程固化成项目仓库 know-u-life 里的两个 Skill也就是本系列第 1 篇定义的那种工程技能文件acceptance管验收user-sim管模拟用户走查。核心动作只有一个把 AI 看不见的东西全部物化成 AI 能读的文档再让 AI 沿文档走查。4.1 第一步每条用例配一张操作时序表每条用例UC的验收基准不只写功能存在再补一张五列表#用户动作When系统做什么事实用户看到什么Then可观察输出之后能从哪继续出口1对助手说了一句要记的事无任何写库动作气泡回复已记录去事项页找到这条记录这一行不是假设它就是开头那次翻车在表上的样子。Then 列承诺了已记录事实列是空的出口列指向的事项页里没有这条记录。三列一对质缺陷自己现形。填表守四条纪律事实列只写系统真实行为落了哪张表、发了什么、改了什么状态。Then 列只断言可观察输出气泡文案、卡片、列表项、计数。“存进 DB”标记 flag不进此列。每行出口必须真实存在UI 里点得到。出口列是规律①的定向探针。感知不得超出事实Then 列比事实列说得多即缺陷。没有时序表的老用例先按五列补表十分钟级。表本身经常就是发现源写不出出口列就是规律①Then 与事实对不上就是规律②。4.2 第二步按时序逐行五问走查对时序表逐行走每行五问。前四问借自认知走查法第五问是 Gherkin 红线与四条规律的合流问抓什么判定为问题的标准① 用户会想做这步吗时序违背目标顺序要求用户先做不关心的决定② 看得到入口吗能力不可见控件不在上一行的出口列里或藏条件后③ 入口能对上号吗语义差一层名字让用户预期 A实际触发 B④ 做完看到进展了吗反馈缺失动作成功后界面无可观察变化⑤ 感知不超过事实吗反馈失真Then 列承诺的多于事实列做的五问里前三问抓路通不通后两问抓话真不真。规律④观感不一致在纸面上现不了形留给第三步。4.3 第三步模拟用户在模拟器上真走一遍文档对质抓纸面矛盾。渲染变形、点击无响应这类只存在于运行时的问题需要在观察空间采样把走查交给一个模拟器 Agent时序表即剧本每行翻译成一条指令做 When 列动作断言 Then 列可观察输出验证出口列可达。模拟用户从找功能变成照用户路线走。边界要说清模拟用户抓不全规律①②。它本来就在找功能不知道能力存在却看不见算问题它没有事实可对照判断不了话术是否失真。这两类只能靠时序表过筛抓。文档走查与模拟走查互补不互替。4.4 组装批次验收公式与三条纪律三步再配上承诺核对组装成每个功能批次的验收公式批次验收 承诺核对当轮产品规格承诺逐条对源码 时序走查当轮 UC 时序表逐行五问 模拟会话一场剧本取自时序表三条纪律保证公式不空转评估者与生成者分离。先列承诺清单再找证据不许边读实现边顺便想想还有什么承诺。从未实现的承诺在代码里没有痕迹只在文档里。证据不足不算通过。没核到的项保持 UNVERIFIED。测试绿是验收的前置条件不构成验收。四规律回写。每条真机反馈先归类到四条规律之一修完必自问同类问题还藏在哪几个功能里然后全量过筛一次。实证一个功能批次246 个测试全绿当天时序走查仍查出已记录未落库和入口缺失两处缺陷。测试绿没有拦住它们时序走查拦住了。五、结论测试绿、用户能用、承诺兑现是三件事AI 改动经常有问题是结构性盲区不是能力缺陷。AI 的感知、行动、断言全部封闭在代码空间用户的四类高频问题全在观察空间且全是时序断裂。验收靠 AI 自己读代码写测试这个洞就补不上。补洞的原理是物化。时序表把用户路线写成资产五问走查把认知走查写成流程模拟会话把运行时观察采样进来。AI 依然没有眼睛但每一步验收都被要求对着用户看到什么的文档举证。三条红线值得直接写进每个项目的验收纪律。Then 只断言可观察输出忍住别查数据库Gherkin动作之后必须看到进展认知走查第④问时序是骨架功能是肉User Story Mapping。测试绿、用户能用、承诺兑现三者要分别验证。第一句验证代码按设计工作第二句验证设计按用户预期工作第三句验证文档没有虚报。AI 的默认工作循环只覆盖第一句。参考资料Cucumber. Gherkin ReferenceGiven/When/Then 与 “忍住别查数据库” 红线NN/g. Cognitive Walkthroughs四问走查法NN/g. Journey Mapping 101actor/场景/阶段/机会点碎片化理解病灶Jeff Patton.User Story Mapping: Discover the Whole Story, Build the Right Product. O’Reilly, 2014本文写作风格依据写作风格提炼论文 OpenAI/Anthropic 官网本文实践载体know-u-life 工程.agents/skills/acceptance三轨验收体系与.agents/skills/user-sim模拟用户走查本文属于「AI Coding」系列文章第 10 篇AI Coding 系列0-工程化视角理解AI Coding与LLM应用的上下文演化1-如何在真实项目中设计一套可落地的Skills体系2-从写了不用到精准触发Claude Code Skill 实战编写指南3-Multi-Agent 协同与边界从单 Skill 到多 Agent 的演进4-自动化发布从手动粘贴到脚本发布踩过的坑5-Pi Agent Harness一个极简终端编码Harness的解构6-Meta-Harness 与 Harness 生态当 Agent 框架本身变成可编排的7-上下文税AI 工作流膨胀的病理与治理8-治理先行Skill 筛选、评估与工作流治理闭环9-常见问题与处理11-功能各有各的账旅程没有总账需求与产品割裂的病理与补法当前文章本文