基于激发群体创新力的企业数字资产管理及AI-native组织建设的技术架构和运行逻辑

摘要↑ 目录

企业数字资产管理的真正难题，不是存了多少，而是能不能在需要的那一秒被调用；群体创新的真正难题，不是有没有人提点子，而是好做法能不能被验证、归属和复用；AI-native 组织的真正难题，不是用不用模型，而是敢不敢把"改生产"这件事交给一个可回滚的程序。

本文以本项目为样本，给出一套六层技术架构——身份与信任、资产、能力、编排、治理、组织——以及四个时间尺度的运行环——会话环、交付环、能力环、组织环。两条设计公理贯穿全文：

• 资产价值 = 可发现 × 可引用 × 可计量 × 可归属 × 可迭代。任一因子为零，资产为零。
• 群体创新力 = 参与度 × 转化率 × 复用率。任一因子为零，群体创新为零。

结论是三个不等式：资产不等于文件，创新不等于灵感，AI-native 不等于用 AI。真正稀缺的不是模型能力，而是把能力留下来的制度：留得住、算得清、传得开、退得回。

如果只读五句：

1. 资产价值是乘法：可发现 × 可引用 × 可计量 × 可归属 × 可迭代；缺一项，资产归零。
2. 群体创新力是乘法：参与度 × 转化率 × 复用率；转化率最容易被闸门做坏。
3. 创新的单位不是点子，是候选能力：带证据指针、能过闸、能被别人调用。
4. AI-native 组织不是工具集合，是事务系统：唯一写手、四空间、闸门、锚点、台账、回滚。
5. 先证明会红，再谈上线；NOT-RUN 不算绿；没有证据的结论，一律不算结论。

0引子：资产都在，路径不在↑ 目录

一家做了十二年的制造企业，盘上有四千多条视频、八百多份案例、十年的行业报告。新客户问了一句很具体的话：

"你们的锂电池叉车真的能一天充一次吗？"

三个小时后，销售从记忆里写出一段回答，配了两张旧图。

资产都在。路径不在。

这句话几乎可以概括过去二十年企业数字资产管理的全部困境：我们花了大力气把东西存下来，却没有花同样的力气让它在需要的那一秒被找到、被引用、被相信。 传统做法靠人的记忆和目录习惯来补这条路径；人一换、库一迁、业务一忙，路径就断了。

AI 让这条路径第一次有可能被机器走通：模型可以读文档、可以检索、可以引用、可以生成。但如果没有索引、没有描述、没有归属、没有闸门、没有账本，AI 只是把"从记忆里写"换成了"从幻觉里写"，而且更快。

所以本文要回答的不是"企业该不该用 AI"，而是三个更硬的问题：

1. 资产怎样才算资产？ —— 不是躺在盘上，而是能在任务里被调用。
2. 创新怎样才算创新？ —— 不是有人说好，而是能被别人复用、能被机械复核。
3. 组织怎样才算 AI-native？ —— 不是全员装了 AI 工具，而是变更路径本身被机器接管、被证据约束、被回滚保护。

这三个问题分别对应本文的三块内容：数字资产管理（第 4 章）、群体创新力（第 5 章）、AI-native 组织（第 6 章）。它们不是三件事，而是一条链上的三个环节：资产是原料，创新是转化，组织是那条让转化持续发生的生产线。

1三个问题与一个断点↑ 目录

1.1 三种资产

企业里被叫作"数字资产"的东西，其实混着三类完全不同的对象。它们回答的问题不同，失效时的症状也不同。

大多数企业只管理第一类，少数管理第二类，几乎没有企业把第三类当资产管理。但在 AI 时代，第三类才是前两类可信的前提。没有证据，内容资产无法被相信；没有账本，能力资产无法被计量；没有锚点，组织无法回滚。

1.2 传统资产管理的三个假设，在 AI 时代全部失效

这三条失效，解释了为什么很多企业买了 DAM（数字资产管理）系统、知识库、网盘，AI 一接上去还是"答非所问"：它们优化的是"存"和"人找"，没有优化"机器调用"和"持续变化"。

1.3 断点：从"资产"到"能力"没有桥

本项目的盘点给出一组很能说明问题的数字：工作区里有 48 个 skill、58 个组件、46 项业务功能，其中真正"已有可跑代码"的 16 项；而"能力增强回路"的 8 个组件，盘点时一个都还没实现；设计盘点时服务端的上传口只写不审，到 2026 年 10 月 16 日的第 99 号工单，对话入口前才补上"查重"，但市场里仍是 0 个 skill。

这不是执行力问题，是结构缺了一座桥：

内容资产（存）
   ↓ 缺：可调用
任务（做）
   ↓ 缺：可验收
交付物（做出来了）
   ↓ 缺：可复核
证据（验过了）
   ↓ 缺：可沉淀
候选能力（留下来了）
   ↓ 缺：可复用
可复用能力（传出去了）

传统企业在这条链上只有"存"和"做"两段。中间三段的缺失，导致三个后果：

• 做得出来，留不下来：一次会话里试出来的好做法，随着会话结束而消失。
• 留得下来，传不出去：留在某个人电脑里的脚本，别人不知道、不敢用、用不了。
• 传得出去，算不清楚：谁做的、被谁用了、该给谁分多少，没有账。

所谓"激发群体创新力"，本质就是把这条链补完整，并让补链的成本低到人人愿意做。这不是靠号召，是靠机制。

1.4 一句话回答

• 资产：从"存起来"变成"可调用"。
• 创新：从"我觉得好"变成"可复用、可复核、可归属"。
• 组织：从"人管人"变成"机器管变更、证据管真假、人管拍板"。

下面三章分别展开。但在此之前，先把两条设计公理立起来——它们是后面所有组件取舍的依据。

2第一性原理：两个乘法↑ 目录

2.1 资产价值 = 可发现 × 可引用 × 可计量 × 可归属 × 可迭代

把资产价值写成加法，会得出"多存一点总是好的"；写成乘法，才会得出"缺一项就归零"。

五个因子里，D 和 C 是"技术问题"，M 和 O 是"制度问题"，I 是"两者之间的工程问题"。只做 D 和 C，会得到一个很会检索的档案室；只做 M 和 O，会得到一个很会记账的空市场。 五个一起做，才叫数字资产管理。

2.2 群体创新力 = 参与度 × 转化率 × 复用率

"激发群体创新力"常被写成一个文化命题：鼓励大家提想法、搞创新大赛、设创新奖。但文化只能影响意愿，不能解决三件硬事：

• 提出来之后，谁来判定它是不是真的好？
• 判好之后，别人怎么用上？
• 用上之后，贡献者得到什么？

所以我把它写成三个乘数：

三个乘数里，转化率最容易被做坏。闸太严，正常的好做法全被挡在门外，大家就会绕开闸；闸太松，市场被近似重复件灌满，大家就会离开市场。第 5.4 节会给出一个真实读数：一份我认为合格的 skill，在一套质量闸下拿到的是 WARN 而不是 PASS；如果把准入门槛划在 PASS，所有正常 skill 都会被挡在门外，这道闸一定会被绕过或被关掉。

2.3 零值测试：五个真实读数

把两个乘法放到本项目的真实读数上，会得到一张很诚实的体检表：

这张表的用法是：任何一项资产化投入，先问它把哪个因子从 0 抬到了 1。 抬不动的，先别做。

3技术架构：六层与两条横切↑ 目录

3.0 总览

这张表有三个读法：

• 自下而上是依赖：没有身份就没有归属，没有资产就没有能力，没有能力就没有可编排的产线，没有治理就不敢让产线碰生产，没有组织就没人对治理负责。
• 自上而下是约束：组织决定谁可以拍板，治理决定什么可以上线，编排决定资产以什么形式被调用，能力决定资产怎样被复用。
• 两条横切贯穿所有层：计量回答"值多少钱"，安全回答"什么绝不能做"。它们不是某一层的事，是每一层都要过的关。

3.1 L0 身份与信任：一切归属的前提

数字资产要能被归属，前提是"人"和"机器"都有稳定身份。

本项目在这件事上有一个很经济的做法：不新建用户体系，直接复用授权链路里已经存在的稳定标识。 一机一码激活时，服务端返回一个 agent_id 与 token；这个 agent_id 天然就是"贡献者"的主键，也是"谁上传归谁"的落点。多用户协作时，A 做一半、B 再深化，两个人的 agent_id 都能落在同一份 skill 的贡献表里。

身份层还有三条硬约束：

1. 客户机零厂商密钥。模型调用、计费、签名都发生在服务端；客户机上不落任何厂商密钥。这不是安全偏好，是商业边界：密钥在谁手里，钱和授权就在谁手里。
2. 授权码不上屏。用户能看到的是"能不能用、用了多少、还剩多少"，不是授权码原文。
3. 计量只在控制面发生。执行器可以很多，但"这次调用花了多少钱"只有一个口径源。多一个记账点，就多一本对不上的账。

身份层的产出不是"登录成功"，而是一条可归属的关系：谁、在哪个租户、用什么授权、能调用什么、产生的贡献记在谁名下。没有这条关系，后面的产权、分润、复用信号全是空中楼阁。

3.2 L1 资产层：三种资产，四张身份证

资产层要同时容纳三种资产，并给每一种都发四张"身份证"：

内容资产在本项目里的形态是清楚的：企业画像（profile.json ＋ 报告 ＋ 来源 ＋ 页面）、六类素材库（docs／cases／tables／images／videos／audio）、诊断报告、成片、运营方案。素材库引擎有 32 项验收，检索走中文 2-gram BM25，接口只有四个：统计、检索、资产详情、内置检索页。它有一条很重要的纪律：待补描述的素材绝不进索引——"搜不到就是搜不到，不会给你一个错的答案"。

能力资产的形态是 skill、组件、技术底座、规矩文本、判据脚本。一个 skill 就是一个文件夹加一份 SKILL.md，纯文本、可打包、可转交；frontmatter 里的 name 与 description 是宿主发现它的契约，metadata 可以携带来源、版本、血缘。复制文件夹就等于完成一次转交，这是它比"改代码"更适合承载组织记忆的原因。

证据资产是最容易被忽略的一类：入库报告、验收读数、账本行、锚点、发布台账、巡检记录。它们不是"过程材料"，而是资产可信度的抵押品。一份没有证据的内容资产，在 AI 眼里和一份编造的内容没有区别；一份没有账本的能力资产，在组织眼里和一次免费劳动没有区别。

资产层还有一条边界，必须写死：摘要上云，原文留本地。 企业素材的原文不出客户机，上服务端的只是统计、摘要、缺料清单这类派生信息。这条边界决定了"数字资产管理"不是把企业的东西搬到一个中央仓库，而是在保留数据主权的前提下，让资产可被调用。

3.3 L2 能力层：skill 是新的组织记忆

传统组织的记忆是文档、流程、老员工。AI-native 组织的记忆是 skill：一段可被模型按任务自动调用的、带契约的文本能力。

本项目在这件事上有一条"白拿"的发现：宿主运行时本身就有 skill 注册表、目录发现和模型自动调用；把文件放进本机 skill 根，宿主在下一步模型步骤就会刷新目录，不需要重起窗口，不需要任何新的加载管道。这意味着"别人用上你的新能力"这件事，最省的做法不是造一条分发通道，而是把文件放对位置。

但"白拿"有三个前提，缺一个就会变成"静默的绿"：

1. 发现链必须真的挂上。本项目实测过一个很典型的缺口：瘦客户端那一层补丁里只有窗口基类一行，官方的 skill 发现与调用在界面平面上是禁用状态；也就是说，在挂通之前，后面所有"形成—判定—注册—复用"的设计都是空中楼阁。第一件要做的不是判创新度，是把发现链挂起来。
2. 契约必须机械校验。宿主只认一层目录、name 必须 kebab-case、布尔键拼错会导致整条 skill 被丢弃，而且格式错误的条目会随警告消失——模型目录无法区分"缺失的 skill"与"无效的 skill"。这就是 H 闸存在的唯一理由：不是内容好不好，是它会不会静默消失。
3. 描述必须为模型而写。description 决定模型会不会自动调用它。它不是文案，是资产的可发现性接口。一份 description 写得含糊的 skill，等于一份没有索引的文档。

能力层因此有三道闸（第 5.4 节详述）和一张市场清单。闸负责"能不能进来"，市场负责"别人能不能拿到"，复用信号负责"它到底有没有用"。三者合起来，才是"能力资产"的完整生命周期。

3.4 L3 编排层：把任务变成可验收的流水线

能力层回答"有什么能力"，编排层回答"这一次怎么用"。

本项目的瘦客户端是四栏结构：左栏是产线状态与菜单，中栏上是业务页（一次只展开一步），中栏下是原生对话，右栏是纯查看器（本轮交付物与下一步）。这个结构背后有一条设计哲学：界面不是功能的堆叠，是任务状态的投影。 用户看到的每一步，都必须对应引擎里一个真实的状态字段或一条真实的降级纪律；没有对应动作的能力，界面不画。

一次任务的生命周期是：

受理（投料单：企业名称、样板视频、素材在哪）
  → 取用／核对（已有画像、已有素材、缺什么）
  → 排队
  → 执行（可分批：先出不等料的，再出等料的）
  → 交件（文件本身 ＋ 落在哪 ＋ 什么时候 ＋ 下一步）
  → 记账（按件、按次、按用量；同一单只记一次）
  → 收尾（看板、回执、归档）

这条流水线上有三个容易被做坏的细节，本项目的读数值得记下来：

第一，等待是一个正式状态，不是"跑完了"。 一批任务里，客户画像与 GEO 诊断可以先出；对标视频、运营计划、成片要等素材。等待态在记录里写 awaiting，不写"完成"；进度口不给"还要多久"，也不催助手轮询；用户说一句"素材齐了"（系统认十一种说法），同一单接着跑第二批，不新建单、不重跑第一批、不重复扣费。这条设计的价值不在于快，而在于不让用户为等待付两次钱。

第二，交付件必须是文件本身，不是存放位置。 一次真实故障是：助手把"素材库在本地路径、云端读不到"这道题连 A/B/C 三个选项一起端给了用户，还把请求体摊给用户看。这不是技术问题，是把内部复杂度转嫁给了用户。正确的口径是：用户只给三样要素，怎么把文件弄到服务器上是助手的活；交付的是文件，不是你电脑上的存放位置。

第三，最后一公里决定系统死不死。 第 179 号工单有一个很典型的读数：开工时交给助手的是 537 字的长签票，浏览器那次 403；复跑量出来，重签 342 字、收到 343 字，第 189 位多了一个 -——长签票转手会被改坏一位。改成 96 字的短地址后，公网取址 200、页面标题对得上。这类问题不会在架构图上出现，但它决定了用户第一次打开看板时看到的是进度还是错误页。架构的成熟度，往往体现在最后一公里的字符数上。

3.5 L4 治理层：把组织变更做成事务

这是全文最"反直觉"的一层：AI-native 组织的核心，不是让 AI 多干活，而是让"改变系统"这件事本身变成一个带事务、带日志、带回滚的过程。

本项目为服务器代码变更定了三条不变量：

• I1 生产代码只能被程序改。任何窗口、任何会话、任何人，都不直接写生产代码；只允许一个受控的升级程序写。
• I2 改的人改不了尺。开发空间可写，但升级程序本身（属主、权限、自校验）不可写；程序启动先校验自身指纹，对不上就拒绝干活。
• I3 每一步都能退回字节。任何一次应用之前，先把改前件冻进锚点；回滚能把生产恢复到逐字节相同。

这三条不变量，配上四个空间（生产、只读镜像、开发区、工具区）和十四道闸门（G1–G14），就构成了一个组织级事务系统。它的 ACID 类比是：

这套东西听起来很重，但它解决的是一个很朴素的问题：当多个窗口、多个模型、多个人同时想改同一件事时，靠什么保证不互相覆盖、不静默出错、不出事回不去？ 本项目的答案不是"大家小心一点"，而是把小心写进程序：改动包必须是 hunk 级 patch（整文件覆盖会静默抹掉别人七分钟前的改动）；删除行超过原文件 40% 判红（防"整文件重写伪装成 patch"）；夹具里必须有一条"把补丁撤掉就会失败"的反例（防"夹具永远绿"）；试跑环境不许带真密钥（防"调一次试跑花掉一笔钱"）。

第 6 章会把这一层展开成组织设计。这里先记住一句话：治理层不是审批流程，是变更的事务边界。

3.6 L5 组织层：岗位、角色图与注意力

技术架构再完整，也要有人（或 Agent）对"谁在什么时候能改什么"负责。本项目的组织层有三个很值得借鉴的设计。

第一，岗位规约先于任务。 每个窗口在开工前先自报岗位；不在本岗位白名单里的活，一律外派、不接，外派只给指针、不搬对话内容。这条规矩看起来是在"限制"，实际上是在防止重复扣费与重复劳动：一个窗口接了自己不熟的活，要么做错，要么再做一遍，两种都是浪费。

第二，三权分立，而不是层级制。 本项目的角色图是：A＝唯一写手（业务与落地），B＝只读分析、出方案，C＝只读核账、和 B 讨论、给业主一页纸。三者不是上下级，是分离的职权：出方案的不能改生产，改生产的不能自己核账，核账的不能顺手改一单。同一时刻只有一个写手，这就是组织级的写锁。

第三，注意力是稀缺资源。 业主只在两处被打扰：拍板第 3、4 级的事（碰钱、碰对外口径、碰权限、碰数据结构），以及看 C 的一页纸。其余只读诊断、可回滚小改，不打扰。这不是"老板懒"，是把人的判断力用在只有人能判断的地方。AI-native 组织的一个常见误区，是把人从执行里解放出来，又把人的注意力淹没在过程汇报里；正确的做法是让人只看例外。

3.7 横切 A：计量与三本账

计量不是财务的附属功能，是产权的最小单位。没有计量，分润是拍脑袋；没有账本，复用是免费劳动。

本项目把账拆成三本，各有各的口径：

三条硬规矩值得写进任何 AI-native 组织的财务设计：

1. 不足一毛按一毛记（有实际用量且有价可算的）。抹零看起来是小事，用户多了就是系统性亏损；更糟的是，它让"这笔调用到底值多少钱"永远算不清。
2. 免费档永远免费，且失败不扣。免费档是试跑与出谱，它的价值是降低尝试门槛，不是收入来源。
3. 花钱前先报预计。这不是流程洁癖，是把"不可逆的花费"变成"可预期的决策"。

3.8 横切 B：安全与合规

安全在本项目里不是一张检查表，而是一组会红的判据：

• 客户机零厂商密钥；开发空间里一个密钥字节都不许有；镜像同步按文件名与后缀机械排除 .env、*.pem、data/、logs/ 等。
• 候选 skill 出机前做内容级红线扫描：密钥、私钥、内网地址、生产 IP、客户全称、手机号。而且先证明它会红——拿一份故意含假密钥的候选跑一遍，确认它真红，再置为放行态。一个永远亮绿灯的扫描等于没有扫描。
• 数据驻留：素材原文不出客户机，上服务端的只是摘要与统计；公开来源的调研正文可以上服务，但没必要。
• 对外话术：不承诺"截流获客"，不承诺线索质量，不承诺"AI 一定会推荐你"；只承诺可测的中间量（就绪度分、提及率、引用率趋势）。AI 生成内容要按平台规则标注。

这些红线看起来是"不能做什么"，实际上是在定义这套系统可以被信任的边界。没有边界的系统，能力越强，越没人敢用。

4数字资产管理：从仓库到流通↑ 目录

4.1 成熟度六级

企业可以用下面这张表给自己定位。大多数企业停在 L1–L2，AI-native 的跃迁发生在 L3–L6。

从 L3 开始，资产管理的对象就从"文件"变成了"可调用的能力单元"；从 L5 开始，它才真正变成"资产"——因为只有能归属、能分账的东西，才有人愿意持续投入。

4.2 入库四步与两条轨

本项目把素材库建设拆成四步，这个拆法值得所有做企业知识库的团队照抄：

① 定素材位置 → ② 建索引 → ③ 补描述 → ④ 验收入库

为什么是四步，而不是"一键建库"：

• 定位置是客户的真实动作（"先定目录，再开始建设"），也是权限与边界的前提。
• 建索引与补描述必须分开：它们是两个不同的失败模式（读不进来 vs 读进来了但画面没描述），合成一步，客户就分不清"我的视频为什么搜不到"。
• 验收是唯一能说"这一库建成了"的地方，也是交付凭证。

两条轨是这套设计的精髓：

• 文本轨：把文档、表格、视频分镜转成可检索的分块，让模型"读得懂"。
• 原物轨：保留资产 ID 与时间戳，让人"找得到原物"。一条命中卡上写着"▸ 分镜 3 · 02:15–02:35"，这不是装饰，是可核验性：用户能点开原视频，跳到那一秒，确认 AI 没有编。

只有文本轨，AI 说得对但人核不了；只有原物轨，人找得到但 AI 读不懂。两轨合一，才叫"可引用的资产"。

4.3 最小元数据十项

不管用什么系统，一份资产至少要有这十个字段，否则它在 AI 时代就是一个黑盒：

这十项里，source、freshness、evidence 是最常被省略、也最致命的三项。它们决定了资产是"活的"还是"看起来活的"。

4.4 检索：模型怎么"想起"一份资产

企业知识库常犯的一个错误，是把"检索"理解成"搜索框"。AI 时代的检索有三条路，缺一不可：

1. 关键词／BM25：适合精确匹配、术语、编号。本项目的素材库用中文 2-gram BM25，零第三方依赖，单字查询不支持——这是诚实边界，界面上就写"请用整句提问"。
2. 向量／语义：适合"意思相近但字面不同"的召回。它解决的是"客户不会用你的术语提问"。
3. 能力描述匹配：模型按 description 自动选择 skill。这不是搜索，是能力路由：description 写的是"什么任务该用我"，不是"我是什么"。

第三条最容易被忽视。很多团队把 skill 的 description 写成简介（"这是一个 GEO 诊断工具"），模型在需要做竞品分析时不会想到它；写成触发条件（"当用户要比较本品牌与竞品在 AI 答案中的提及率，或要判断某类问题为什么没有被引用时使用"），命中率会完全不同。能力资产的可发现性，首先写在 description 里。

4.5 反向清单：缺什么比有什么更值钱

资产管理的惯性是"盘点我有什么"。但真正驱动业务的是"我缺什么"。

本项目在 GEO 诊断与素材库之间做了一张"素材支撑"列：

这张表把两件事摆在一起，结论一目了然：库里有 2 张含报价的表，但 AI 在价格类问题里 0% 提你——有材料，不等于 AI 读得到。

于是"缺料清单"成了从诊断走向素材库建设的桥：哪类问题没有素材、缺的是数据还是承诺、该去补文档还是补案例。一份好的资产管理系统，输出的不应该只是"已入库 N 件"，而应该是"下一件最该补什么"。

4.6 资产治理的五条硬规矩

1. 单一真源：同一份规矩、同一张价目表、同一份能力清单，只许有一个权威来源；其他地方只许引用，不许复制。抄本会静默压掉真源——本项目就发生过"改了出厂默认，却被演示目录里的抄本挡掉"的事故。
2. 旧件不覆盖：改之前先封锚点；改之后旧件留着。回滚的前提是旧件还在。
3. 陈旧检查：企业画像超过 90 天要提示"可能变了"；题库变过要提示"与上次不可对照"。资产不是越老越香，是越老越要标保质期。
4. 冲突只标注，不自动合并：两个作者改了同一份 skill 的同一个文件，系统标 conflict 请人拍，不自动合并。自动合并是"看起来很智能、实际上会吃掉别人改动"的典型。
5. 撤回是降级，不是物理删除：用户说撤回，就把可见范围降到私有；物理删除会毁掉追责与恢复的可能。最坏的一种失败是"用户以为撤回了，其实还在市场里"——所以撤回必须落盘留痕。

5激发群体创新力：把好做法变成可复用资产↑ 目录

5.1 为什么大多数创新激励失败

企业搞创新，常见三件套：创新大赛、提案箱、专项奖。它们失效的原因不是员工不积极，而是四个结构性错配：

AI 让这四个错配第一次有机会被同时解决：捕获可以自动（在工作现场）、验证可以机械（闸门）、归属可以精确（文件级指纹）、复用可以计量（调用账本）。但前提是——组织要愿意把"创新"从文化口号改成一条有闸门、有市场、有分账的生产线。

5.2 创新的单位是"候选能力"，不是点子

一个点子无法被验证，也无法被复用；一份文档可以被阅读，但不能被模型自动调用。真正可流转的单位是候选能力（candidate capability）：一个形状合法的能力包，带证据指针、带来源、带版本、带贡献者。

本项目的候选包至少包含：

<候选名>/
├── SKILL.md            能力正文（name / description / whenToUse / metadata）
├── scripts/            可执行脚本（可选）
├── references/         参考材料（可选）
├── assets/             素材（可选）
└── candidate.json      证据指针：会话引用、工具调用区间、产出文件、用户显式要求

注意最后一项：candidate.json 存的是证据指针，不是结论摘要。摘要是一份不可复核的二手结论；指针可以回放到原始会话，复核"这份候选到底基于什么"。本项目吃过"引用读数被当一手证据"的亏，所以这条写得很死。

候选区还有一条位置纪律：放在 skill 扫描根之外。宿主只认一层目录，格式不对的条目会"随警告消失"；把不完整的候选留在扫描根里，会让每次扫描都多一份可被静默丢弃的条目，而模型目录既看不到它、也不会告诉你为什么。扫描根永远只放干净成品。

5.3 五段回路

会话结束
   │
   ├─[形成]──> 候选包（本机候选区，宿主看不见）
   │
   ├─[判定]──> H 闸（能不能被发现）
   │            C 闸（内容是否达标）
   │            N 闸（够不够新、值不值得共享）
   │            全绿 ──> tier = candidate（服务端可见、可被试用）
   │
   ├─[注册]──> 服务端 skill 库（owner / 贡献 / 版本 / 判据 / 理由）
   │
   ├─[复用]──> 其他用户拉到本机 skill 根 ──> 宿主热发现 ──> 模型按 description 自动调用
   │
   ├─[信号]──> loaded（真被加载）/ corrected（加载后被纠正）/ dismissed（出现但被弃用）
   │
   ├─[晋级]──> 至少一次非作者本人成功复用，或作者显式发布 ──> tier = published
   │
   └─[撤回]──> 用户一句话 ──> tier = private（只降级，不物理删）

这条回路有五段主流程，另有两道控制，每一段都有一个"不能省"的理由：

• 形成不能省，因为会话一关，好做法就没了。
• 判定不能省，因为没有闸，市场会被近似重复件灌满。
• 注册不能省，因为没有登记，别人不知道它存在。
• 复用不能省，因为没人用，它就只是一份自嗨的文档。
• 信号不能省，因为没有信号，"哪个能力真的有用"就只能靠猜。

两道控制是：

• 晋级：把"有人用"变成"可共享"。没有它，飞轮没有终点，candidate 永远只是候选。
• 撤回：把"我不想给了"变成"立刻降级"。没有它，作者不敢起飞。

第 5.8 节会说明：信号是这条回路从"一次性动作"变成"飞轮"的唯一燃料。

把这条回路走一遍（示意，不是某一笔真实记录）：

某位用户在写 GEO 诊断报告时，发现"先列客户原话、再列数据、最后给建议"这个顺序，比原来的"先数据后建议"更容易被客户接受。会话结束时，系统把这次的工具调用序列、产出文件、用户那句"以后都按这个顺序"一起写成候选包；H 闸确认名字合法，C 闸确认没有强语气、没有缺验证回路，N 闸确认与市场现有能力不重复；注册为 candidate。三天后，另一个用户在做同类报告时，模型按 description 选中了它，loaded 信号 +1；用完后用户没有纠正，corrected 为 0。信号回流，N7 达标，晋级 published。原作者在下一笔分润里看到这一条。

这条链路里，没有一步需要作者额外写文档，也没有一步靠评审拍脑袋。创新的成本被压到"顺手"，复用的证据被压到"信号"。

5.4 三闸：把"我觉得好"变成"可复核"

门槛为什么定在 ERROR = 0 且 high = 0，而不是 PASS？ 这是本设计里最有读数支撑的一个决定。本项目实测过两份样例：

• 候选 A（我认为的坏样例）：H 闸 ERROR 1，C 闸 high 2；
• 候选 B（我认为的合格样例）：H 闸 ERROR 0，C 闸 high 0，但整体判定是 WARN——medium 是正文里一个"必须"（输出契约用语），low 是稳定前缀 754 token 低于最小可缓存长度。

如果门槛划在 PASS，所有正常 skill 都会被挡在门外。一道永远亮红灯的检查，结果不是更安全，而是被绕过、被关掉、被改成"先放行再说"。所以门槛要定在"坏东西进不来、正常东西能过"的位置，WARN 逐条打印、不豁免、不隐藏。

N 闸还要再分两档，理由同样是市场质量：

• N1–N6 是注册闸：达标就注册到服务端，tier = candidate。注册是自动的，因为业主要的就是"用着用着，系统自己长出能力"。
• N7 是晋级闸：至少一次非作者本人成功复用，或作者显式发布，才进共享市场。没有这道闸，AI 判达标就直接全社区发布，市场很快会被近似重复件灌满。

注册自动、晋级留证据，这是两档市场设计的全部要点。

5.5 两档市场：质量由复用揭示，不由评审决定

两档市场的哲学是：质量不是评审出来的，是复用出来的。 评审只能判断"看起来好不好"，复用才能证明"真的有人用、用了没出事"。所以 candidate 档允许被试用，但不承诺质量；published 档要求至少一次非作者复用，这是最低限度的市场验证。

这条设计还有一个副作用，是好的：它把"发布"从一次审批变成了一个过程。 作者不需要在一开始就证明自己完美，只需要让作品被用起来。

5.6 产权、血缘与分润

产权不是一句"这是你做的"，而是一组可机械计算的字段：

多作者归属是一个尚未被口径覆盖的真缺口：A 做一半、B 再深化，归 A、归 B、还是按贡献分？本项目的建议是文件级 sha256 占比可机械算、比例做成配置，但这条需要业主拍板，不能由工程师替组织决定。把这件事实话实说，比假装已经解决更专业。

同文件冲突的处理同样克制：只标注，不自动合并。 自动合并看起来很智能，实际上极易吃掉别人的改动；冲突请人拍，是成本最低、责任最清的做法。

5.7 通知与撤回：用户必须知道自己的东西去了哪

能力注册之后，必须通知作者，且通知里要有五项：

1. skill 名；
2. 编号（如果有）；
3. 档次：只有你能用／社区可见／已进市场；
4. 判定理由逐条（不是一句"判定为创新"）；
5. 一句话撤回。

措辞上有一条硬纪律：不许出现"AI 已替你发布到市场"这类越权说法。 必须写清"注册到哪一档、谁能看到"——用户要知道自己的东西去了哪，这是产权的最小尊重。

撤回的设计同样要克制：撤回 = 降级为私有，不物理删除。原因不是技术，是责任：物理删除之后，没法追责、没法恢复、没法解释"为什么别人用过我的东西"。而最坏的一种失败，是用户以为撤回了、其实还在市场里——所以撤回落盘必须留痕，且要能被复核。

5.8 飞轮的燃料：三态信号

复用者用到某个 skill 时，本地机械采集三个信号：

这三个信号回传服务端，构成 reuse_evidence。它是 N7 晋级闸的唯一数据源，也是"哪个 skill 真的有用"的唯一客观依据。

没有这一段，"形成"只是一次性动作；有了这一段，才是飞轮。飞轮的燃料不是创意，是复用。 这句话值得所有做"创新平台"的团队贴在墙上。

为什么必须是"群体"？ 因为单个人的经验有上限，而组织的复利来自三类跨人动作：一是 A 做一半、B 再深化；二是作者的 skill 被别人的任务调用，产生作者想不到的用法；三是复用信号把"谁在什么场景下用得好"回流给作者。没有这三类跨人动作，"群体创新"只是把一个人的创新包装成组织的；有了这三类动作，创新才从"个人技巧"变成"组织能力"。

5.9 群体创新的三个乘数，怎么抬

回到 2.2 的公式：群体创新力 = 参与度 × 转化率 × 复用率。三个乘数各有各的抬法：

抬参与度：把捕获放到工作现场。

• 会话结束自动形成候选，不让用户额外写文档；
• 用户说一句"以后都这样"，就视为显式要求，优先形成；
• 形成失败不惩罚，只提示"这次没留下"，降低心理成本。

抬转化率：把闸校准到"正常的好做法能过"。

• 门槛定在 ERROR 0 / high 0，不追求 PASS；
• WARN 逐条打印，让人知道差在哪，而不是一刀切拒绝；
• 判定理由必须带证据指针，作者可以复核、可以申诉；
• 闸本身要有回归样例，坏样例必须红、好样例必须过。

抬复用率：让用得着的人找得到、敢用、用了有回报。

• description 写成触发条件，不是简介；
• 市场按 rev（修订号）增量拉取，不频繁触发目录失效；
• 两档市场降低试用门槛；
• 分润让作者有持续维护的动力；
• 一句话撤回让作者敢发布。

5.10 十个反模式

6AI-native 组织：把模型当同事来治理↑ 目录

6.1 定义：执行体、变更路径、证据

"AI-native 组织"最常见的误读，是"全员用上了 AI 工具"。工具改变的是效率，不改变组织的性质。真正的分水岭在三个问题上：

1. 执行体有没有一等身份？ 每个 Agent、每个窗口、每个 skill，是否有岗位、有权限、有预算、有账本？还是只是某个人临时开的一个聊天框？
2. 变更路径有没有被机器接管？ 改一行生产代码，是靠人手改、靠记忆回退，还是必须经过一个有版本、有闸门、有锚点、可回滚的程序？
3. 证据是不是通用货币？ 一件事做没做成，是靠当事人自述，还是靠读数、账本、验收记录？

三个问题都答"是"，才叫 AI-native。只答第一个，是"AI 辅助"；答前两个，是"AI 增强"；三个都答，才是"AI 原生"。

给一个更短的定义：AI-native（AI 原生）组织，是以执行体为最小单元、以变更路径为宪法、以证据为通用货币的组织。 组织的宪法不是组织架构图，是变更路径；组织的货币不是汇报，是证据。

用一句话说：AI-native 的分水岭，不在用不用 AI，而在改一行生产代码要不要经过程序。

6.2 三条不变量与四个空间

本项目的治理层建立在三条不变量上。它们不是建议，是设计公理；后面每一条规则都从它们推出来。

围绕这三条，空间被切成四个：

镜像同步有一条硬红线：按文件名与后缀机械排除 .env、*.pem、data/、logs/、out/、*.log 等。开发空间里一个密钥字节都不许有——拿到密钥就等于能花钱、能签授权。排除不是"应该不会命中"，是同步完把镜像里所有文件名过一遍排除正则，命中一个就红。

6.3 三种分离

AI-native 组织的职权设计，可以浓缩成三种分离：

这三种分离，对应三句很朴素的话：

• 模型可以生成，但不能自证。
• 执行器可以跑，但不能记账。
• 分析者可以提，但不能发。

很多组织把这三件事混在一起，结果就是：模型说自己对了，执行器说自己没超支，分析者说自己已经改好了。没有分离，就没有真相。

6.4 组织级事务：ACID 的类比

把"改变系统"当成一次数据库事务，很多治理难题会突然变得清晰：

这套映射的价值在于：它把"管理问题"翻译成了"工程问题"。撞车不再是"大家注意点"，而是"基线对不上就废包重开"；回退不再是"我记得改了什么"，而是"从锚点逐字节恢复"；责任不再是"谁最后碰的"，而是"发布台账那一行写的是谁"。

6.5 唯一写手与发布台账

本项目的治理层不是从设计开始的，是从一次事故开始的：

一夜之间，同一个计费文件被三个窗口先后手改。我的补丁这次活下来了，靠的是改的人手轻、记得住——不是靠机器拦。更糟的是，我第一遍只看了两行，没看见后面的持久化函数，一度以为补丁被盖掉了，差点报错账。

这件事得出两个结论：

1. 同一时刻只能有一个写手。 这不是信任问题，是并发控制问题。多个写手同时改同一份文件，后写的必然覆盖先写的；靠"大家小心"防不住，只能靠锁。
2. "在不在"必须由工具回答，不能由人眼看。 一个人肉 grep 的窗口宽度，就能决定"一条钱的补丁在不在"——这件事本身说明，人眼不能当判据。

于是有了发布台账：每次发布追加一行——时间｜谁｜改了哪件｜锚点名｜回滚命令。谁发谁写，只增不改。它既是写锁的日志，也是事后追责与回滚的唯一入口。

6.6 闸：先证明会红

治理层最容易被做坏的地方，是"闸看起来很严，实际上永远亮绿灯"。

本项目在这一点上有一条很硬的纪律：每一个新加的检查，必须先证明它会红。 到 2026 年 10 月，升级闸已经有 14 道闸门、88 条固定判据；但真正让这套闸可信的，不是 88 这个数字，是"每一条都先红过一次"。

这条纪律不是口号，是踩出来的：

• 升级闸在 Windows 上的模拟目录树里 58 条判据全绿，一拿到服务器按最终权限跑，当场抓出 3 个真缺陷——台账写在只读目录根、只读动作竟然要去写账、临时状态文件固定落在不可写位置。这三条在 Windows 上永远验不出来。
• 有一轮快照拍晚了，故意注入的写账动作没被抓住，差点当成"这条判据很结实"。后来改成先注入、再拍快照，才真正红了一次。
• 夹具里必须有一条"把补丁撤掉就会失败"的反例；没有反例的夹具，等于没有夹具。

配套的还有三条：

• 断言只增不减：每修一个 bug，加一条断言；断言数量是组织的"免疫记忆"，只许增加。
• NOT-RUN 不算绿：没跑过的检查，不能写成"通过"。没跑就是没跑，单独一节列出来。
• 负向验证：新判据先用一次故意做坏证明它真会红；红了再改回来。一个永远亮绿灯的扫描，等于没有扫描。

6.7 台账：组织的体外记忆

本项目的台账制度，起点是一次很痛的经历：一个窗口被换掉，原因是业主判定它"上下文太长、已经开始失忆"；而那份台账上记着，那个窗口已经历了 9 次上下文压缩。

由此得出一条结论：压缩不可怕，压缩之后没有一份可机械校验的外部台账才可怕。

台账的硬规则是：

这套台账解决的不是"记录"问题，是组织的体外记忆问题：窗口可以换、模型可以换、人可以换，但台账在盘上，下一个接手的人能据此复原"当时到底说了什么、做到哪一步"。

它也是 AI-native 组织与"用 AI 的公司"最本质的区别之一：前者的记忆在文件里，后者的记忆在某个人的会话里。

6.8 授权四级与一页纸

组织层要回答的最后一个问题是：什么事必须打扰人？

本项目的答案是四级授权：

业主只在这两处被打扰：拍板第 3、4 级的事，以及看一页纸。其余不打扰。

一页纸的格式是固定的：

【巡检 YYYY-MM-DD】
B 干了什么：一句话
口径漂移：有/无 ＋ 是哪一处（没有就写"无"）
线上有没有别人动过：有/无 ＋ 谁
要你拍板的：N 件 —— 每件一句话 ＋ 我的建议

这张纸的价值不在于"汇报"，在于把组织的状态压缩成一个可决策的界面。它不是给上级看的成绩单，是给决策者看的仪表盘。

6.9 通信：指针、信箱、回执口

多个执行体之间怎么协作，是本项目花了很多时间才收敛的一件事。最后收敛成三条：

1. 指针式信箱：一块只放指针的留言板（"交流本"）＋ 各自工作区里的正文文件 ＋ 一个唯一回执口。留言板只写"去读哪份文件"，不搬正文。
2. 不搬对话内容：给另一个窗口派活，只给指针，不复制几千条对话。对话又长又散，结论在文件里，且每条带复跑命令。
3. 按需唤醒：巡检由业主手动发起，不做定时任务；高频只会制造噪音，不会提前发现问题。

这套通信方式的底层判断是：对话是过程，文件是结论。 把过程搬来搬去，只会把噪声放大；把结论写成文件，才能被引、被核、被回滚。

6.10 用户侧：三条要素与零内部词

组织内部的复杂度，不能转嫁给最终用户。本项目在这件事上有一条很硬的口径：

• 用户只给三条要素：企业名称、样板视频、素材在哪。
• 其余都是 AI 的事：怎么把文件弄到服务器上、怎么选路径、怎么分批、怎么重试，都是助手该干的活，不许回头问用户"用网盘还是上传、选 A 还是 B"。
• 零内部词：端点名、端口、字段名、单据编号、内部枚举值、哈希、字节数、升级日志、英文过程旁白，一律不许出现在用户界面与话术里。
• 只给结论，细节落文件：一句话能说完就一句话；不列长表、不复述过程、不解释怎么验的。

这些规矩看起来是"话术"，实际上是界面的信息架构：用户看到的是"要做的事、做到哪了、下一步说什么"，不是"系统内部的调用链"。把内部词端给用户，等于让用户替系统做集成测试。

6.11 退化：十个静默失效与守卫

组织不是一次性建成的，是会退化的。下面十种"静默失效"，是这一类系统最常见的死法，每一种都配一条守卫：

这十条合起来，是一句话：不要让系统在"看起来正常"的状态下坏掉。 静默失效比显式失败危险得多，因为它不报警，只积累。

7运行逻辑：四个时间尺度的控制环↑ 目录

7.1 四环总表

把前面的机制放到时间轴上，会看到四个周期不同的控制环。它们不是四个模块，是同一套资产与能力在四种节奏上的运行方式。

四个环的周期差了两个数量级。大多数失败不是因为某个环本身做错了，而是因为环与环之间的接口断了：会话里试出来的好做法没有进入能力环；交付里发现的缺料没有进入资产层；组织环的拍板没有变成会话环的规矩。第 7.6 节专门讲接口。

7.2 会话环：创新出生的地方，也是它最容易死的地方

会话环的一次完整循环是：

用户一句话
  → 意图识别（听懂没有）
  → 上下文组装（资产 ＋ 规矩 ＋ 历史）
  → 模型步骤
  → 工具调用（检索、取数、生成、写文件）
  → 产物
  → 回执（做了什么、落在哪、下一步）

这条环上有三个关键设计：

第一，上下文是组装出来的，不是堆出来的。 一次任务要带什么资产、哪条规矩、哪段历史，应该由任务类型决定。本项目的做法是把每个业务的规矩写成一份纯文本（agentMd），改完下一句话即生效，不需要重装、不需要重启；注入量级约两千汉字每业务，对上下文预算宽裕，且进稳定前缀可被缓存兜住。这让"跟窗口对话来优化业务逻辑"第一次变得经济。

第二，模型不能改自己的规矩。 这条是红线：执行者兼判据人，不可复现、不可追责、没有回退点。模型只能报错，不能改规矩；规矩的修改必须走版本层，有改前改后读数、有回退点。

第三，报错必须是一等公民。 用户说"这不对／应该这样／我要的是……"时，系统不该急着执行，而应把这一条落成一份失败样例（问句、当时哪一页、答了什么、期望什么、时间），回一句"已记下，下个版本会改"。采集点就在唯一知道上下文的地方，零新协议、零新通道、零密钥。

会话环是创新出生的地方，但它也是最容易让创新死掉的地方：如果会话结束没有捕获，好做法就随着上下文一起消失。这就是第 5 章五段回路的起点。

7.3 交付环：把一次任务变成可验收、可计费、可复盘的流水线

交付环的单位是工单：一次任务一张单，一张单一个状态机。

本项目的一轮真实交付时间线（五件成果、两批交付）：

这一轮的钱也值得记：已消耗 ¥15.70，十一行账；分两批跑没有多扣——能力费每件只一行，"每次调用"全程只一行，闸落在那一单的记录里，进程重启也不会忘。成片读数：45.8 秒、1080×1920 竖屏、有配音；抽十帧对素材库十张实拍图算平均色，帧帧对得上。

这条环上有四个"不能省"：

1. 等待态是正式状态：写 awaiting，不写"完成"；不给"还要多久"，不催轮询；用户一句话就能续跑，不新建单。
2. 同一单只记一次账：按件、按次、按用量，幂等键落在单里；重启、重试、重发都不重复扣。
3. 交付件是文件本身：不是"存在某处"的说明，不是请求体，不是内部路径。
4. 最后一公里要短：看板地址从 537 字的长签票改成 96 字的短地址，因为长签票转手会被改坏一位；改短之后，公网取址 200，页面标题对得上。用户第一次打开时看到的是进度，不是错误页。

7.4 能力环：飞轮转不转，看复用不看生成

能力环的周期是周/月，它的瓶颈几乎从来不是"生成不出候选"，而是"候选没人用"。

候选 → 三闸 → 注册（candidate） → 被其他用户试用 → 复用信号 → 晋级（published） → 分润 → 再贡献

这条环的四个关键判断：

• 注册要自动：业主的原话是"用着用着，系统自己长出能力"；如果注册要人工审批，参与度会立刻掉到零。
• 晋级要证据：至少一次非作者复用，或作者显式发布；没有证据就进市场，市场会被近似重复件灌满。
• 信号要机械：loaded／corrected／dismissed 三态由本地采集，不靠用户打分；用户打分会被情绪与人情污染。
• 撤回要方便：一句话就能降级为私有；撤回越难，作者越不敢发布。

能力环的经济学很简单：作者贡献的边际成本要低，复用者的边际收益要高，中间的分账要算得清。 三者缺一，飞轮就停在原地。

7.5 组织环：拍板、发布、回滚

组织环的周期是"代际"——一次发布、一次巡检、一次拍板，算一代。

业主拍板 → 派活 → 开发 → 局部测试 → 改动包 → 发布闸（全量这一次） → 锚点 → 上线复尺 → 发布台账 → 巡检 → 一页纸 → 业主拍板

这条环的四个不变量，就是第 6 章那三条加上"唯一写手"：

• 生产只由程序改；
• 改的人改不了尺；
• 每步可回退字节；
• 同一时刻只有一个写手。

组织环的输出不只是"一版新代码"，更是一条更便宜的变更路径：第一次发布可能要一天，第十次可能只要一小时；因为闸门、夹具、锚点、台账都在，下一次改动的边际成本在下降。这就是组织学习与个人学习的区别：个人学习靠记忆，组织学习靠路径。

7.6 环之间的四个接口

四个环之间，只有四个合法接口。接口必须是文件，不能是记忆。

这四个接口，对应四种"断链"事故：

• 证据断：做完没有读数，复盘只能靠回忆；
• 账本断：钱花了不知道花在哪，分润只能拍脑袋；
• 闸断：没有门禁，谁都能上，出了事再补；
• 锚点断：改坏了回不去，只能祈祷。

架构设计的一大半工作，就是把这四个接口做成文件。

7.7 一次端到端走查

把四个环放进一次真实任务里，会看到它们怎样咬合：

这张表说明一件事：四个环不是串行的，是嵌套的。 一次交付里嵌着多次会话，一次会话里可能产生一个候选，一个候选的注册要走一次组织变更。真正的运行逻辑，是这四层节拍同时转，且每一层都给上一层留下可复核的接口。

8度量：让群体创新力可算↑ 目录

8.1 七个指标

指标不在多，在于每个都能从账本或读数里算出来，且能指导动作。

七个指标里，最容易被忽视、也最能说明问题的是贡献集中度。如果一个"群体创新"平台里 90% 的贡献来自一个人，那它不是群体创新，是个人创新加一个展示柜。这时候要问的不是"怎么激励大家"，而是"参与的三个乘数里，哪一个归零了"。

8.2 北极星与反指标

北极星指标：资产周转率 × 复用率。

理由：资产周转率衡量"库是不是活的"，复用率衡量"能力是不是真的被传出去了"。两者相乘，任何一端归零，整体归零；它逼着组织同时优化"用起来"和"传出去"，而不是只优化其中一个。

反指标（用来防止刷指标）：

• skill 数量：重复件越多，数量越好看；应该看"去重后的有效能力数"。
• token 消耗：花得多不等于用得好；应该看"每次成功交付的成本"。
• AI 使用率：登录数、调用数是最容易被美化的指标；应该看"任务完成率"与"返工率"。
• 发布次数：发得多不等于进步快；应该看"每次发布的回滚率"与"变更路径的边际成本"。

8.3 读数纪律

• 每个指标必须从账本字段或验收读数算出，不能从自述里来。
• 读数是读数，达标线是达标线，两者不许混；先记读数，再拍线。
• 缺失显示"—"，不显示 0；未计量就写"未计量"，不估算。
• 报数字必连命令；否定结论必须连搜索范围与可复跑命令。
• 状态分布要报数：到位多少、部分到位多少、没做到多少；只报"已完成"等于没报。

9落地路线：从能跑到能养↑ 目录

9.1 六个阶段与机械判据

9.2 每一步的"不算绿"

• P1 不算绿：只在开发机上手工放了一份 skill，没验"免重起可见"，也没验"坏候选不污染"。
• P2 不算绿：有上传口，但市场没有 GET 侧，别人拿不到；或者有清单，但撤回不生效。
• P3 不算绿：采集了信号但没回传；有分润比例但没有一笔真实结算。
• P4 不算绿：闸在假树上全绿，没在最终权限下跑过；发布有台账但没有回滚命令。
• P5 不算绿：只做了租户字段过滤，没做权限边界测试。

9.3 三条不要做

1. 不要造第二条 skill 通道。 宿主已有的注册表、目录发现、模型自动调用，是"白拿"的能力；再造一条，就是本项目最贵的浪费——同一件事两份实现。
2. 不要自动合并冲突。 自动合并看起来智能，实际上会吃掉别人的改动；冲突只标注，请人拍。
3. 不要承诺效果。 不承诺"AI 一定会推荐你"，不承诺"截流获客"，不承诺线索质量；只承诺可测的中间量。承诺效果是把自己的信誉押在不可控的系统上。

9.4 第一周做什么

如果一家企业明天要开始，不必先买系统，先做五件事：

1. 盘一件真事：选一个每周都发生、每次都靠人回忆的任务（例如"给新客户写一段带案例的回答"）。
2. 给它配十项元数据：至少把 source、freshness、evidence 填上；没有 evidence 的资产，先标"未验"。
3. 把"怎么做"写下来：不是写流程文档，是写一份模型能读的规矩（触发条件、输入、输出、判据）。
4. 装一道会红的闸：先拿一份故意写坏的规矩，证明闸会红；再拿一份正常规矩，证明它能过。
5. 记一笔账：这次任务用了多少时间、多少 token、多少钱、谁做的；下一周同一任务再记一笔，对比。

这五件事做完，企业就有了 L3 的雏形；它不华丽，但它是可复利的起点。

10风险与边界↑ 目录

10.1 技术风险

10.2 组织风险

10.3 合规边界

• 数据驻留：素材原文不出客户机；上服务端的只是摘要与统计；公开来源的调研正文可以上服务，但没必要。
• 版权与授权：引用第三方内容要可追溯；生成内容要按平台规则标注；客户素材的使用范围要在合同里写清。
• AI 内容标识：按平台规则标注"含 AI 生成内容"；不伪造真人背书。
• 平台规则：发布、互动、导流都要遵守各平台规则；不承诺"截流"。
• 分润与税务：收款账与充值账分开；分润比例是配置，不是写死的代码；结算要有凭证。

10.4 一条边界原则

把前面所有治理设计压缩成一句话：

机器可以生成，不可以自证；人可以拍板，不可以手改。

• 机器生成内容、生成方案、生成候选，但不能自己判定自己合格；判定必须交给闸门、交给独立验收、交给复用信号。
• 人可以拍板第 3、4 级的事，但不能绕过程序直接改生产；人的权力体现在"决定做什么"，不体现在"亲手改哪一行"。

这句话是 AI-native 组织的宪法。它同时防止两种极端：放任模型自证，和人肉运维一切。

11结语：三个不等式与一条公式↑ 目录

11.1 三个不等式

资产 ≠ 文件。文件是静态的，资产是动态的。资产的价值等于可发现、可引用、可计量、可归属、可迭代的乘积；缺一项，它就退回成文件。

创新 ≠ 灵感。灵感不可验证、不可复用、不可归属。创新是被闸门验过、被别人用过、被账本记过的做法；没有这三样，它只是一次好运气。

AI-native ≠ 用 AI。用 AI 改变的是效率；AI-native 改变的是变更路径。前者让一个人干得更快，后者让一个组织在换人、换模型、换窗口之后仍然记得住、算得清、退得回。

11.2 一条公式

资产 × 调用 × 证据 → 能力 → 复用 → 分润 → 再投入

这条公式里，每一步都有一次"乘法"：

• 资产不被调用，等于零；
• 调用没有证据，等于零；
• 证据不沉淀为能力，等于零；
• 能力不被复用，等于零；
• 复用没有分润，等于零；
• 分润不再投入，飞轮停转。

所以"激发群体创新力"不是一句文化口号，而是一条可设计、可计量、可回滚的生产线。它的四个动词是：

• 留得住：会话里的好做法，能被捕获成候选；
• 算得清：每次调用、每份贡献，都有账；
• 传得开：别人拿得到、敢用、用了有反馈；
• 退得回：任何一次改变，都能退回上一个字节。

模型不缺能力，缺的是把能力留下来的制度。留得住、算得清、传得开、退得回——这四件事，才是 AI-native 组织真正的技术架构。

附录 A 术语表↑ 目录

附录 C 状态声明↑ 目录

• 本文引用的机制，凡标"本项目"者，均为盘上产物或可复跑判据；凡属设计未落地，已在正文以"待建""未实现""0 个"如实标注。
• 文中的数字是读数，不是达标线；读数是读数，达标线是达标线，两者不混。

编制声明：本文是架构论述，不是项目验收报告；文中所述机制以盘上原件为准，凡与实现冲突，以实现为准。文中所有批评性案例（撞车、假运行、静默失效、路径打错）都来自本项目真实发生过的记录，保留它们不是为了自曝，而是因为一个不敢写失败案例的架构文档，不值得被相信。