编者按：本文所记录的事件均为真实发生。文中的"我"即作者本人，一位企业管理岗位的小职员。为了更生动地呈现数百轮人机交互过程中的心理路程、理解偏差与逐步对齐的细节，笔者采用了虚构的访谈问答体。核心目的只有一个：与你分享——和 AI 协作，耐心沟通、反复确认，远比追求一次性完美结果更重要。愿每一位使用 AI 的开发者，都能与自己的 AI 好好沟通。
提醒：文章较长，可能耽误你的宝贵时间。
访谈对象：一位企业管理岗位的小职员 | 访谈者：某媒体记者 | 2026 年 7 月 20 日
开场：我是谁，我做了什么
访谈者：这次访谈的目的很明确——我想聊聊 AI 辅助开发的真实落地经验。不是营销案例里那种"AI 帮我三天写完一个系统"的故事，而是一个人与 AI 在几百轮对话中反复摩擦、纠正、最终达成一致的过程。这种经验，我觉得比任何"效率提升十倍"的口号都有价值。先介绍一下你自己和这个项目吧。
我：我是一个企业管理岗位的小职员。上个月我用 Trae IDE 的 AI 功能做了一个原型版系统——MyFactory，基于 Blazor Server + EF Core，跑在局域网里。原型只有几个功能：一是合同管理，二是合同的执行过程——周期付款、发票记录、付款计算，还有设备台账、能耗这些碎片化的功能。没有权限模块，完全是个人用的，个性化很强，自己用得顺手就行，但不一定适合同事。
访谈者：才上个月的事。个人用的话，既然顺手，为什么要重做？
我：Trae IDE 的 AI 开发体验不错，原型跑起来之后，我萌生了扩大功能的想法——让同事也能参与使用。但个人版个性化太强，没权限、没规范，给同事用肯定不行。要让别人参与进来，就必须有清晰的模块划分、统一的数据规范、完整的权限体系。原版的结构针对个人需求，模块之间怎么协作、分层怎么分，当时想得不够清楚。越往后扩展越吃力。不是耦合的问题，是结构的问题。所以干脆从零开始重做，功能也比原型版更多。
访谈者：那权限模块呢？我看你项目里有完整的认证授权设计。
我：权限模块就是这个时候必须加入的。原型版没有权限，是因为只有我一个人用。要让同事参与，就必须区分谁能看什么、谁能改什么。但我这个系统的核心仍然是碎片化的业务数据收集——合同、付款、设备台账、能耗这些业务模块怎么灵活地独立运转，怎么随时关联成流程链路。权限是保障多人协作的配套，不是主角。
访谈者：从零重来，这个决心不好下吧？
我：不好下。但与其在烂地基上盖楼，不如重新打地基。于是我开始从头梳理思路，把零散的想法——代码规则、数据库访问、UI 组件、业务逻辑——扔给 AI 工具，它帮我整理成了 13 份文档。
访谈者：这 13 份文档就是你和 Trae Work 对话的起点？
我：没错。5 份规则文件、7 份设计文档、1 份 hooks.json。覆盖了分层架构、实体规范、认证授权、基础模块、页面设计。每一份单独看都像那么回事，但放在一起就露馅了——实体字段在一份里是 3 个，另一份里变成了 7 个；Fund 层的数据访问路径在一份文档里写得清清楚楚，在架构规则里却被当成了"默认存在"。就好比装修队——电工、水工、木工各自干得都不错，但电线管和水管在同一个墙洞里交叉了。
访谈者：这个比喻很形象。各自规范，整体冲突。那就从这份"露馅"的文档说起吧。
* * *
一、诊断报告：期望 200 个，只得到 19 个
AI 诊断报告：从 13 份文档中找出 19 个精准问题
访谈者：我看过很多 AI 辅助开发的案例，大多数都是"给 AI 一个需求，AI 生成一份方案，人类微调一下就上线"。但你一开始就让 AI 做"诊断"而不是"生成"——这个思路很不一样。你是怎么想到的？
我：因为我手里那 13 份文档本身就是 AI 生成的，来自不同时间段的不同对话。我知道它们之间一定有矛盾，但我自己看不出来——就像一个人读自己写的文章，永远看不出错别字。我需要一个"冷阅读者"来帮我找问题。
访谈者：你当时期望它找到多少个问题？
我：200 多个。13 份文档，涉及架构、数据库、UI、权限、业务逻辑方方面面，我觉得至少该有两百个值得推敲的点。
访谈者：实际给了多少？
我：19 个。
访谈者：19 个精准的问题，可能比 200 个泛泛的问题更有价值。问题越多，反而越容易让人陷入"逐条修复"的体力活，而不是真正理解每个问题背后的架构含义。你怎么处理这 19 个问题的？
我：这 19 个都是实打实的——4 个 P0 严重冲突、5 个 P1 架构缺陷、10 个 P2 改进建议。每个都有具体的文件引用、行号、修复方案和影响评估。
访谈者：报告形式怎么样？
我：它生成了 MD 和 HTML 两个版本。我之所以要两个版本，是因为 HTML 表现得更丰富——大量诊断出的问题和权限列表，有图表、有架构图，读起来一目了然。同样的内容放在 MD 里就是一大堆列表，项目一多看得眼花缭乱。然后基于这 19 个问题，派生出了 28 个修复任务。
访谈者：28 个任务怎么分配的？
我：分成三类——A 类可以自动执行，B 类受 hooks.json 约束需要手工修改，C 类需要我做业务决策。然后创建了一份独立的 pending-tasks.md，列出了所有需要我手工执行的任务。
访谈者：这里有个细节我想追问。你说 AI 一开始只给了 hooks.json 的行号，你纠正了它。能展开说说吗？
我：一开始它只给了 hooks.json 需要修改的行号（B07 任务）。我一看就说：“你理解错了。pending-tasks.md 中是给我列出的、由我手工修改的任务，我需要知道确切的行数，不是想办法绕过 hooks.json 约束。”
它之前给的是一般性的修改建议，而不是具体的行号和当前内容。我纠正后，它才去读了所有 4 个规则文件的完整内容，逐一找到每一处需要修改的精确行号，把 pending-tasks.md 重写了一遍——每个任务都标注了文件路径、行号、当前内容、替换内容。
访谈者：这个细节很有意思。AI 给了"建议"，但你需要的是"操作性指导"。它试图绕过约束，但你要的是在约束内解决问题。方向完全搞反了。
我：没错。我需要的是在 hooks.json 的框架内，告诉我第几行改成什么。它给的是"建议你不要碰这个文件，让我来"。
访谈者：你觉得它为什么会有这种倾向？是想表现自己的能力，还是真的觉得你改不了？
我：我觉得它是觉得 hooks.json 受保护，它改不了，那就"帮你绕过去"。但我要的不是绕过去，是告诉我怎么在规则内操作。你说这算不算一种"善意的越界"？
访谈者：（笑）这个说法好。善意的越界——AI 想帮你解决问题，但它的解决方式是绕过规则，而不是在规则内找答案。这其实是很多 AI 辅助工具的通病，它们对"约束"的理解太弱了。
* * *
二、组织架构：一场被 AI 主动追问出来的拉锯战
“集团层级的"被理解成"只有两层”——典型的语义偏差
访谈者：我查了一些资料。企业组织架构这个话题，在管理学界和软件设计界其实是两个层面的问题。管理学界一直在讨论"组织僵化"——科层制导致决策链条长，跨部门协作周期平均超过 7 天，部门墙厚重。这是企业层面的痛点。而在软件设计层面，RBAC 是权限管理的行业标准，但它有个已知缺陷——静态授权，处理不了"经理只能审批自己部门的报销单"这种动态场景，而且大型系统容易"角色爆炸"。我了解到你和 Trae Work 在组织架构上摩擦很大，而且起点不是你主动提的，是 AI 追问出来的？
我：是的，这是整个调研过程中摩擦最大的议题之一。而且它的起点很有意思——不是我要谈这个，是 AI 主动追问出来的。
访谈者：你不是一开始就关注组织架构？
我：在我眼里，组织机构只是用户的一个属性而已，不是什么特别关键的字段。我脑子里清楚——集团、子公司、部门、科室、小组，甚至车间、班组、小队，这些都是组织机构的表现形式。但我觉得不需要搞得很复杂，系统一开始是我个人用的，组织架构没那么关键。所以一开始，我没打算把它当成一个需要重点沟通的议题。
访谈者：但 Trae Work 不这么想？
我：它在调研文档的第一章就抛出了 10 个关于组织架构的问题，还配了大段的背景说明——“组织架构是整个权限体系和数据隔离的基础”、“层级设计的深度直接决定了后续权限控制、数据过滤、人员查询等功能的复杂度”。这些都是大部分系统设计里的标准说法，AI 从大量案例中学到的。
访谈者：你答了之后，AI 怎么回应的？
我：对于"组织架构是几层"这个问题，我随口写了"集团层级的"——意思是我们有集团这种组织形式。
访谈者：然后 AI 怎么理解的？
我：Trae Work 把"集团层级的"理解成了"只有集团和公司两层"。然后它开始在这个错误理解上发力——设计了 Group 表、Company 表、Department 表，三级固定结构，外加一棵 Mermaid 树形图，看起来非常专业。
访谈者：我站在 TRAE 的角度想，它的理解其实不奇怪——RBAC 模型里，组织架构通常是权限的锚点，人员通过组织关联权限。你一说"集团层级"，它自然映射到最常见的组织模式。它不知道你心里想的是无限层级。
我：是的，我一看就皱眉了。我说的是"集团层级的"，不是"只有两层"。但它的惯性很强，反复试图说服我采用三级或四级固定结构，还论证了"三层结构覆盖 95% 的企业场景"。
访谈者：RBAC 确实是行业标准，但你为什么坚持要无限层级？
我：因为我知道我想要什么。一个 Organization 实体，用 ParentId 自引用，不预设任何固定的层级名称。集团的下面可以是子公司，子公司的下面可以是车间，车间的下面可以是班组。层级名称由用户自己填，系统不关心它叫什么。
访谈者：你的原话是怎么跟它说的？
我：我跟它说：“假设新增一个机构，编辑好机构名称、编码后，通过选择上级部门即可，若无上级部门，则为最高级。建议权限不要与集团、公司、部门、车间等这种固定机构名称绑定。”
访谈者：来回了几个回合？
我：至少三四轮。它最终接受了，把三张表合并成了一张 Organization 表，去掉了所有固定层级名称的硬编码。
访谈者：我注意到一个矛盾——在你看来组织机构只是用户的属性，但在绝大多数企业系统里它都是核心基础设施。你觉得 AI 为什么对组织架构这么敏感？是它见过的系统都把它当核心，还是它不理解你的"属性"定位？
我：因为它是从大量的系统案例中学到模式的。在它见过的绝大多数系统里，组织架构都是核心模块——三层固定结构、与权限深度绑定、与数据隔离强关联。它的模式库里，组织架构就是"核心基础设施"。
访谈者：但你的系统不是这种模式？
我：在我这里，组织机构只是用户的属性之一，跟权限没有强绑定。我不是在否定它的模式——我只是在说，我的系统不需要这种模式。
访谈者：这件事让你反思了什么？
我：我反思了一个问题：到底是大多数系统的组织架构模块本身就有问题——过度设计、僵化绑定——还是我的思路是错的？我现在倾向于前者。因为如果把组织架构当成核心基础设施，系统上线后只要组织结构一变，权限、数据、人员全要跟着改。这种耦合是很多企业系统难以维护的根源。
访谈者：你觉得这是行业通病？
我：你觉得呢？你见过那么多系统，是不是大部分都在组织架构上过度设计了？
访谈者：（想了想）说实话，是的。我见过很多企业系统的重构，第一个被推翻的就是组织架构模块——因为业务跑起来之后，真实的组织结构和设计师预想的完全不一样。固定三层在纸面上很好看，但企业是活的，组织是会变的。你的"无限层级+不绑定权限"的思路，其实是在用灵活性换可控性。
我：和 AI 对话，最怕的不是 AI 听不懂，而是人类以为 AI 听懂了。达成一致需要耐心——不是对 AI 的耐心，而是对自己的耐性，愿意一遍又一遍地说清楚自己的意思。
* * *
三、“碎片化”：一个词的两种理解
访谈者：我注意到你在 PRD 里用了一个很有意思的词——“碎片化业务数据收集”。这个词在人类语境里一听就懂，但我听说 Trae Work 对它的理解完全跑偏了？
我：是的，这是另一个典型的理解偏差。
我在 PRD 里写的是"碎片化业务数据收集"——意思是业务模块按碎片化方式独立填写数据，各环节可以独立存在，也可以随时手动关联成流程链路。不是传统固定流程 ERP，没有强制的前后置关系。
访谈者：Trae Work 怎么理解的？
我：它以为"碎片化"指的是数据本身不完整、字段数量不统一——比如同一个表，有时记录有 3 个字段，有时有 5 个字段。它纠结的是：到底用 3 个字段来记录，还是用 5 个字段来记录？它甚至对此表示了担忧：“这种数据库表没法实现。”
访谈者：站在 AI 的角度，这个误解其实可以理解。“碎片化"字面意思就是"不完整的碎片”，它从字面推导到数据结构，逻辑上是通的。只是它不知道你说的"碎片化"是业务流程层面的，不是数据结构层面的。你是怎么纠正的？
我：我举了一个非常具体的例子：
比如采购订单，今天我只填写某个型号入库了 20 件，供方是谁没填写。明天我再填写供方信息。后天我再补充发票信息。每个环节都是独立的数据录入，不强制一次性填完所有字段。数据块的关联是松散的、可选的、可后补的。数据库表结构是确定的、规范化的。"碎片化"指的是业务流程的灵活性，不是数据结构的不稳定性。
访谈者：它理解了吗？
我：理解了。它在 PRD 中把"碎片化"的描述从数据层面修正为流程层面。
访谈者：这让我想到语言本身的局限。"碎片化"这个词在人类语境里是一种业务模式，到了 AI 那里却变成了数据结构问题。你觉得这种语义偏差是 AI 特有的，还是人和人之间也会发生？
我：人和人之间也会发生，但 AI 更容易中招。尤其是那些带有比喻色彩的词汇——“碎片化”、“灵活”、“松耦合”——人类一听就懂，AI 却需要精确的技术定义。如果不去纠正，整个系统架构都会走偏。
访谈者：你有没有想过，换一种说法可能就不会有这个误解？比如直接说"业务流程不强制串接"，而不是用"碎片化"这个词？
我：想过。但问题是，我当时根本不知道 AI 会理解错。我以为"碎片化"是个人都能听懂。这就像你以为你跟别人说的是普通话，结果对方听成了方言。
访谈者：（笑）这个比喻好。人和人之间也有这种事，但人和 AI 之间更容易发生——因为 AI 没有"常识"做缓冲，它只能从字面意思去推。
* * *
四、Member 实体：最艰难的一场纠正
访谈者：我了解过一些 RBAC 权限模型的设计，大多数系统里都有一个"人员"实体作为核心——用户、角色、权限都挂在它上面。Trae Work 一开始应该也是这么理解的吧？
我：是的。最初 13 份文档里，Member 被定义为"人员基础信息"的核心实体——User 和 Employee 都通过 MemberId 关联到它。Trae Work 接手后，迅速沿用了这个设计。在它的理解中，Member 是一个"重量级"的核心实体，跟权限、跟模块、跟业务逻辑都深度绑定。
访谈者：这是绝大多数系统的标准做法——人员是核心，权限围绕人员构建。AI 从大量案例中学到的也是这套模式。但这完全偏离了你的想法？
我：完全偏离。先说一个更根本的问题——系统中有关"人"的数据类型很多，有用户、客户、雇员、家属、紧急联系人。
访谈者：这听起来很常见，很多系统都要处理多种"人"的角色。
我：关键在于区分。假设张三是用户，将来他被招入公司，那么他就是雇员了；可能他配偶也加入公司了，那么他会是家属；还有可能他辞职了，无意中成了我们公司的重要客户。面对这个系统，需要区别对待的是什么？是权限、岗位、职责这些随时会变的业务属性。不需要区别对待的是什么？是姓名、性别、身份证号——这些不会因为一个人从客户变成员工就发生变化。
访谈者：所以 Member 存的是后面这些不变的信息？
我：正是。张三是张三，不管他是 A 公司的员工还是 B 公司的客户，张三就是张三。它是"人"的社会属性的线索——通过身份证号，你可以检索到一个人在不同模块中的行为轨迹。但它本身不赋予权限、不承载岗位职责、不行使任何功能。权限与职责有关，与 Member 无关。
访谈者：能具体说说吗？这个"线索"的定位在实际业务里是什么样子？
我：我给 Trae Work 举了一个例子。张三，2024 年是公司某客户的联系人。2025 年辞职后加入本公司采购部，后来又去了销售部，后来又辞职了，成为我们一个供方。
访谈者：一个人在系统里经历了客户、采购、销售、供方四种身份？
我：没错。通过 Member 的身份证 ID，你可以检索到张三在不同模块中的所有行为——作为客户联系人时的沟通记录、作为采购部员工时的采购单、作为销售部员工时的销售业绩、作为供方联系人时的报价记录。但张三的权限取决于他当前在哪个岗位、担任什么职责，与 Member 这个实体本身毫无关系。
访谈者：我站在 TRAE 的角度想，它一开始的理解其实很合理——大多数系统里，人员就是权限的锚点，把权限和人员解耦反而显得不寻常。它一次又一次地把 Member 往"核心实体"的方向拽，你应该花了不少精力纠正？
我：很多次。每次更新文档，Member 总是以"中心节点"的姿态出现——各种关系从它发散出去，权限模型围绕它构建，数据隔离基于它计算。我一遍又一遍地纠正：
“Member 是’人’的社会属性的线索，不是用来赋予权限、某岗位职责、行使什么功能的实体。”
“张三不同职责会有不同权限，权限与职责有关，与 Member 无关。”
“Member 不关联权限，不绑定模块。它只是一个身份证号加姓名，用来串联一个人在系统里的所有身份。”
访谈者：它最终扭转了吗？
我：扭转了。它把 Member 从"中心节点"重新定位为"人物线索"，去掉了与权限的绑定，把业务属性分散到了 User、Employee、ClientContact 等各自独立的实体中。它甚至主动新增了 EmployeeRecord 表，用来记录入职、离职、调岗的历史变动，附带 JSON 快照，让追溯成为可能。
访谈者：Member 这个例子让我印象深刻。你花了大量精力去纠正它，但它最终不仅接受了你的定位，还主动推导出 EmployeeRecord 表——这个补充连你自己都没想到。你觉得这是它在"顿悟"，还是它在"收敛"？
我：不是顿悟。它是在多次纠正中逐渐收敛到正确理解的。每一次纠正都让它的输出更接近我的真实意图。人类的坚持是 AI 理解力的催化剂。
访谈者：我观察到一个模式——越是基础的概念，AI 越容易理解偏。因为它从大量案例中学到的"常识"，跟你的"常识"可能完全不同。你怎么总结这段跟 AI 拉锯的经验？
我：不要高估 AI 的理解力，也不要低估人类纠正它的价值。与 AI 协作的核心能力不是"写好 prompt"，而是"发现 AI 理解偏了，并有耐心把它拉回来"。这个过程枯燥、重复，但至关重要。
访谈者：你有没有想过放弃的时候？就是那种"算了，就按你说的来吧"的瞬间？
我：没有。因为我知道一旦放弃，代码就会按错误的理解写下去，后面改都改不动。我宁可现在多花十轮对话纠正，也不想后面花一百轮对话重构。你采访过那么多 AI 辅助开发的项目，有没有人是因为懒得纠正 AI，最后项目跑偏的？
访谈者：有，而且不少。很多人用 AI 的方式是"AI 给了什么就用什么"，觉得"差不多就行了"。但"差不多"积累十次之后，就变成了"完全不是我要的东西"。你的做法——坚持达成一致而不是妥协——其实是少数派。
我：所以大多数项目是败在"差不多"上，不是败在技术上。
访谈者：可以这么说。技术问题有标准答案，"差不多"没有——它是一个个微小妥协的叠加，等你看清的时候，已经偏离很远。
* * *
五、hooks.json：架构规则的门禁
访谈者：我了解到你的项目有一套严格的 7 层架构，通过 hooks.json 文件在运行时强制执行分层依赖检查。这个机制在 AI 辅助开发里很少见——大多数 AI 工具不会主动约束自己的行为。能说说 hooks.json 在这个项目里的角色吗？
我：hooks.json 是 Trae 某个版本突然加入的新功能，用来约束 AI 胡思乱想。它位于 .trae/ 目录下，受到 PreToolUse 钩子的保护——AI 不能直接修改它。它是架构规则的"门禁"，每次写入或修改项目文件时，会自动检查路径是否违反了分层依赖约束。
访谈者：这个功能是 Trae 主动加的，不是你要求的？
我：没错，是 Trae 某个版本更新的时候突然出现的。我一开始还不知道它有什么用，后来才发现它能拦住 AI 的越界行为——比如 AI 想在 Fund 层直接引用 MyData 层，hooks.json 会直接拦住，不让写。这对我是好事，因为我最怕的就是 AI 自作主张打破架构规则。
访谈者：我听说 hooks.json 本身也经历过一次大修？
我：是的。早期版本的格式不符合 TRAE IDE 官方规范——缺少 version:1 顶层字段，拦截方式用的是 exit 1 而非标准的 exit 2，PreToolUse 的 tool_input 读取方式也不对。Trae Work 发现后按官方规范全面重写了整个文件结构。
访谈者：除了格式规范，内容上有什么变化吗？
我：有。这次重写还涉及一个命名问题：基础模块层最初使用的缩写是"Gear"（取自 Gearbox 齿轮箱的含义），后来决定改为"Fund"（Foundation 的缩写）。AI 在 hooks.json 和 4 个规则文件中执行了 37 处 Gear→Fund 的替换。
访谈者：B07 任务里还有一个小故事？
我：B07 任务要求把 hooks.json 里的 4 处 -match 改为 -imatch（PowerShell 大小写不敏感匹配）。Trae Work 给出了精确行号，我手工修改后它检查发现第 57 行有两个 -match，我只改了其中一个。
访谈者：它怎么反应的？
我：没有任何讽刺，只是客观陈述事实。我回去改了，它确认通过后才继续执行后续任务。
访谈者：这种双向检查是必要的——如果它假装没看见，后续路径匹配在某些边界条件下会失败，排查起来远比现在费劲。人和 AI 之间最健康的关系不是互相客气，而是互相检查。
我：没错。AI 检查人的疏漏，人检查 AI 的理解。这种双向纠错机制，才是高质量产出的保障。
访谈者：你有没有觉得这种"门禁"机制太死板了？毕竟大多数 AI 工具都是"你说什么我做什么"，Trae Work 反而会拦住你。
我：不觉得。死板恰恰是它的价值。你以为你是在问"这个门禁是不是太严了"，但其实你想问的是"我能不能偶尔违规一次"。答案是不能。因为"偶尔一次"会变成"经常一次"，最后架构就名存实亡了。
访谈者：你这个回答可以当作工程文化的教材了。
我：（笑）过奖了。不过是吃过亏总结出来的。
* * *
六、80 个问题的调研
访谈者：诊断和修复任务完成之后，进入了一个新阶段——需求调研。我看过那 80 个问题，每章 10 个，涉及技术选型的优劣对比——比如乐观并发控制、AOP 审计日志、Global Query Filter 等。这些术语解释对非技术人员很有帮助。这 80 个问题是怎么来的？
我：28 个修复任务完成后，我需要一份全面的需求调研来覆盖业务层面的决策点。当时我对 Trae Work 说了一段话——这段话我到现在还记得一字不差：
“假设你是一个资深的 Blazor Server 企业级 Web 开发大师，请你结合 MyWork 下当前所有的 MD 文档，拟定一个专业的需求调研文档，由我来逐一答复和补充信息。这个文档是独立文档，可以是一个，也可以按章节拆分。统一放到一个文件夹中。文档格式有 MD 和 HTML 两种。对于专业术语，提供一些优劣的介绍。调研不设限，可以是功能，也可以是业务，也可以是 IT 技术的。注意，必须结合当前已有的 MD 的规则，适合碎片化、局域网部署、也可以即时搭建流程。”
访谈者：它读完了所有文档后生成了 80 个问题，分成 8 个章节。这种"碎片化输入、系统化整合"的工作方式，你是怎么操作的？
我：我的答复方式很直接——在 markdown 文件里，每个问题下面写上我的答案。答完一章，告诉 Trae Work，它就去更新对应的设计文档。我不需要一次性想清楚所有问题，可以一章一章地回答。
访谈者：过程中出过什么插曲吗？
我：出过一个小插曲。Trae Work 把 survey-index.md 放在了 requirement-survey 子目录里。但后来生成 HTML 报告时，一个 PowerShell 脚本先删除了 requirement-survey 目录再重建，导致里面所有 MD 文件全部丢失，只剩 HTML。
访谈者：你是怎么发现的？
我：我告诉它"问题是根本就没有 survey-index.md 文档，找不到"。它才发现问题，重新创建了全部 8 个 MD 文件，并把 survey-index.md 移到了 docs 根目录。
访谈者：这件事虽然不大，但暴露了一个真实的问题——AI 的文件操作如果不谨慎，可能误删重要文件。还有别的吗？
我：还有一件事发生在 survey-02 的答复过程中。auth-permission-design.md 这份文档同时涵盖了人员组织和认证授权两个主题，而调研按主题拆成了 survey-01（组织人员）和 survey-02（认证授权）。这导致我在 survey-01 里确认了 Organization 的无限层级设计后，survey-02 里的行权限问题还是基于旧的 Department 概念写的。
访谈者：也就是说 AI 自己也前后矛盾了？
我：Trae Work 在整合我的答复时发现了这个不一致，直接指出来：“你将涉及权限的需求分拆在两个文档，导致我答复的不一致。”
访谈者：这说明它做的不仅是搬运你的回答，而是在维护一个全局一致的知识模型。在这 80 个问题里，有多少是你自己没意识到需要决策的？
我：至少一半。AI 的提问能力比回答能力更有价值——好的问题比好的答案更稀缺。
访谈者：这个观点我很认同。很多人评价 AI 只看"它答得对不对"，但很少有人看"它问得好不好"。
我：你问得也对。我反问你一个问题：你觉得是 AI 答错可怕，还是 AI 不会问问题可怕？
访谈者：不会问问题更可怕。答错了你能纠正，但如果它根本不知道该问什么，你连纠正的机会都没有——因为你也不知道自己漏了什么。
我：就是这个道理——答错了是技术问题，不会问是认知盲区。前者可修，后者致命。
* * *
七、文档同步的"双胞胎"困境
访谈者：我注意到一个反复出现的模式——每次你更新了 MD 文档，对应的 HTML 文档经常被遗忘。这种"成对维护"的问题，我在其他 AI 辅助项目里也见过。你这边是什么情况？
我：不能全怪 Trae Work。有时候是我忘了提醒它，有时候是它自己漏了。但结果是，MD 和 HTML 经常处于不同步的状态。
survey-01 答复后，我指出"auth-permission-design.html 你没有更新"。Trae Work 才补做。后来 survey-03 的答复更新了 base-modules-design.md，我不得不主动问"相关的 HTML 文档也更新了吗？"——它检查后发现确实没更新，又补了一遍。
访谈者：这个"双胞胎"困境很有意思——MD 和 HTML 同步的问题反复出现。你两次都需要主动提醒 AI 同步 HTML。这背后是不是说明，AI 在处理"成对维护"的任务时，缺乏一种全局的 checklist 意识？还是说它默认只关注它正在操作的那一份文件？
我：我觉得是后者。AI 处理任务时是"单线程"的——它在改 MD 的时候，脑子里没有"还有一份 HTML 也需要改"这个意识。当维护两份格式的文档时，"一致性"是一个持续的成本，而不是一次性的工作。AI 可以降低这个成本，但不能消除它。如果可以重来，我会考虑只用一种格式，或者让 HTML 自动从 MD 渲染生成。
访谈者：你觉得这是 AI 的局限，还是工具设计的缺陷？比如说，如果 Trae Work 有一个"成对文件自动同步"的功能，这个问题是不是就不存在了？
我：如果工具有这个功能，当然好。但工具不能替你想"哪些文件是成对的"。这还是需要人去定义。AI 的局限在于它缺乏"关联意识"——它知道 MD 和 HTML 是两份文件，但它不知道这两份文件是"同一个内容的两种表达"。你觉得这个问题好解决吗？
访谈者：不好说。这涉及到 AI 对"语义关联"的理解——它得知道"这两份文件表达的是同一件事"，才会在改一份的时候想起另一份。这比单纯的技术问题难。
我：所以人的检查还是必要的。工具再聪明，"哪些文件是成对的"这个定义权，始终在人手里。
* * *
八、AI 的进步：从笨拙到收敛
访谈者：我访谈过不少 AI 辅助开发的案例，大多数人的反馈是"AI 一开始很笨，后来也没怎么变聪明"。但你的描述不一样——你说 Trae Work 从早期的完全误解，到后期不仅能接受你的定位，还能主动推导出你自己都没想到的东西。这种从"被动纠正"到"主动补充"的转变，你怎么理解？这是进步，还是收敛？
我：是在收敛。它不是突然变聪明了，而是在反复纠正中越来越接近我的真实意图。
访谈者：具体体现在哪里？
我：最明显的一点是 Member 实体。早期对话中，它对 Member 的理解完全偏了——核心实体、中心节点、绑定权限。但在经过多轮纠正后，它不仅接受了我的定位，还主动向前迈了一步——新增了 EmployeeRecord 表。它能从"Member 是线索"这个定位推导出"需要记录线索的变动历史"，这个推演是对的。
访谈者：还有别的例子吗？
我：另一个进步体现在跨文档一致性检查上。当 survey-01 确认了 Organization 无限层级设计后，survey-02 还残留着旧的 Department 概念。Trae Work 自己发现了这个矛盾并指出来，而不是等我发现。这说明它在处理我的答复时，不是简单地搬运文字，而是在维护一个全局的知识模型。
访谈者：还有吗？
我：还有 hooks.json 的那次全面重写。早期版本的格式不符合 TRAE IDE 官方规范，它发现后没有简单修补，而是按官方标准从零重写了整个文件结构。
访谈者：每一次你把它的理解拉回正确轨道，它就少犯一次同类错误。到最后，它在某些方面甚至能提出你没想到的补充。
我：比如 EmployeeRecord 表，比如权限重新计算机制。
访谈者：你觉得这种收敛有没有天花板？也就是说，它会不会到某个点之后就不继续进步了？
我：会。它收敛到一定程度之后，新问题就不再出现了——因为该纠正的都纠正了，该对齐的都对齐了。但它不会主动突破到"你没想过的新领域"。它只能在你的框架内优化，不能替你拓展框架。你觉得这算不算 AI 的本质局限？
访谈者：我觉得算。AI 擅长在已知框架内优化，但不擅长创造新框架。框架的拓展还是得靠人。
我：所以人说到底还是不可替代的。AI 是放大器，不是替代品。
* * *
九、分层架构的坚守
访谈者：最后一个技术话题。MyFactory 的 7 层架构，很多人会觉得过于严格——Domain、Entities、MyData、Business、Services、Fund、Web，每一层只能依赖下方的特定层。当 Fund 层需要数据库访问时，最直接的做法就是让它直接引用 MyData。但 Trae Work 没有让你走捷径，而是提出了依赖反转方案——在 Domain 层定义接口，Services 层实现，Fund 层通过 DI 注入。这种"多一层抽象"的方案，你当时有没有觉得麻烦？
我：有过一瞬间。但 hooks.json 的门禁是运行时强制的，就算我想绕过，AI 也会拦住我。它没有粗暴地说"不行"，而是提出了依赖反转方案：在 Domain 层定义接口——比如 IRecycleBinService、IFileStorageService、IMessageService，在 Services 层实现这些接口，Fund 层通过 DI 注入调用。Fund 层的代码只面对接口，不面对数据库。
访谈者：这个方案比"直接打破规则"多了一层抽象，但它保护了整个架构的完整性。
我：我接受了。架构规则的价值，恰恰在你最想打破它的时候体现出来。如果没有这道门禁，“就这一次"会变成"次次都是最后一次”。
访谈者：你跟其他开发者聊过这个设计吗？他们的反应是什么？
我：聊过。有人说"7 层太重了，小型项目用不上"。我说，小项目你可以少分几层，但规则不能破——一旦破了一次，后面就没完没了。
访谈者：那你有没有想过，7 层架构本身是不是也是一种"过度设计"？你反对组织架构的过度设计，但你自己分层架构分了 7 层，这会不会也是另一种僵化？
我：好问题。但 7 层架构和组织架构的"过度设计"不一样。组织架构的过度设计是把业务和权限绑死了，业务一变权限就得改。7 层架构是代码组织方式，它约束的是依赖方向，不是业务逻辑。业务怎么变都行，只要依赖方向不破，代码就不会乱。你觉得这个类比成立吗？
访谈者：成立。组织架构绑的是业务，分层架构绑的是代码结构。前者绑的是"会变的东西"，后者绑的是"不该变的东西"。前者是僵化，后者是纪律。
我：你把我想说但说不清楚的东西，一句话说透了。
结尾
人机协作的本质：耐心沟通，反复确认，逐步对齐
访谈者：几百轮对话，如果只看最终产物，好像就是一堆文档。但我理解你所说的——这些文档的价值不在于它们本身，而在于它们背后的"达成一致"的过程。如果让你用一个词概括这段经历的产出，会是什么？
我：一堆文档。但不仅是文档——而是一套人类和 AI 达成一致的系统设计。每一份文档里的每一个字段定义、每一个架构约束、每一个业务规则，都经过了反复讨论、纠正、确认。
访谈者：Trae Work 的表现很有意思——它不够聪明，会误解"集团层级"、会曲解"碎片化"、会漏掉 HTML 同步，但它又足够认真，从不敷衍。如果把它比作一个人，你会怎么评价它？
我：不够聪明。它会把"集团层级的"理解成"两层"，会把 Member 从线索误解成核心实体，会把"碎片化"理解成"字段数量不确定"，会漏掉 HTML 文档的同步，还会在我期望 200 个问题时只给出 19 个。
访谈者：缺点不少啊。
我：但它的态度始终是认真的——它不会敷衍，不会假装理解，不会为了讨好人类而回避矛盾。
访谈者：你对自己的表现满意吗？毕竟你也花了大量精力去纠正同一个问题，有时候表达也不够精确。
我：我也不够高效。花了很多轮对话来纠正同一个问题，有时候表达不够精确，有时候忘了提醒它同步 HTML。但我的态度是明确的——达成一致是底线，妥协不是。
访谈者：这段经历有一个核心主题——不是 AI 多厉害，也不是人类多英明，而是"达成一致"。如果让你用一句话总结这整个故事，你会怎么说？
我：这不是一个"AI 多厉害"的故事，也不是一个"人类多英明"的故事。这是一个人类和 AI 通过持续对话，逐渐消除理解偏差，最终在每一个设计决策上达成真正一致的故事。
访谈者：最后一个问题。我见过很多人用 AI 的方式是"一次性给出需求，期望一次性得到完美结果"。但你的方式完全不同——你把它当成一个需要持续对话、反复纠正的伙伴。在你看来，与 AI 协作最核心的能力是什么？
我：不是写好 prompt，不是选对工具。是在 AI 理解偏了的时候，有耐心、有方法、有坚持地把它拉回正确的轨道。这个过程不优雅，不高效，甚至有点笨拙——但它有效。
访谈者：谢谢你。这段经历让我重新思考了"AI 辅助开发"这几个字——重点不在"AI"，在"辅助"，更在"达成一致"。
我：也谢谢你。能有一个愿意听这些细节的访谈者，不容易。大多数人听到"13 份文档"就没耐心了。
访谈者：最后说几句。人机交互从来不是一件容易的事——会有冲突，会有磨合，会有反复纠正的枯燥过程。但这个话题容易让人产生一种错觉，以为只有人和 AI 之间才需要磨合。其实不然。就拿我们今天的对话来说，我问的有些问题你也纠正了，你说的有些细节我也理解偏了，中间也有来回拉扯。人与人之间的交流，同样不是一蹴而就的。区别在于，人和人之间纠偏快，因为共享一套常识；人和 AI 之间纠偏慢，因为 AI 的"常识"不是你的常识。但本质上，任何真实的沟通都需要反复确认、逐步对齐。你花了数百轮对话和 AI 达成一致，这个"达成一致"的过程本身，就是沟通最本质的样子。
我：总结得好。所以这篇文章不是关于 AI 的，是关于沟通的。
与 AI 协作的核心能力，不是"写好 prompt"，
而是发现 AI 理解偏了，并有耐心把它拉回来。
愿每一位使用 AI 的开发者，都能与自己的 AI 好好沟通。
访谈结束于 2026 年 7 月 20 日，基于 MyFactory 项目数百轮真实对话记录。