← 返回概念解读

Concept Fable精修版

技术文档

Technical Documentation · Compliance/Documentation

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

没有图纸的水车,修好一次就会再坏一次

溪谷里有一架水车,最早由老匠人亲手搭成。它能带动磨坊、灌溉田地、给染坊送水。老匠人知道每根木轴的脾气,却很少写下来。

水车接的活越来越多,旁边又加了暗渠、分水闸和夜间警铃。新学徒只会照着老匠人的手势做,没人完整理解水从哪里来、经过哪里、什么时候会停。

第一次故障后,坊主让学徒写一张维修心得。心得里满是小技巧,却没有总图、接口、限制、变更记录和应急步骤。下一次坏在别处,心得几乎用不上。

一场寒潮冻裂暗渠,老匠人不在城里。学徒们围着水车争论半夜,最后关错了闸,磨坊没救成,染坊也停了。

老匠人回来后,没有责怪学徒。他把水车画成几层图:总体结构、每个闸门的责任、正常水路、异常水路、维护周期、禁止改动的部位。

他还要求每次改动都写清原因、影响范围、测试结果和回退办法。图纸不再是竣工纪念,而是水车继续运行的一部分。文档也分给不同读者。学徒看日常维护,验收官看安全边界,坊主看影响范围,外来工匠看接口和禁区。写清楚这些,水车才不只靠某个人的记忆活着。

几个月后,新学徒能独立处理小故障,外来的验收官也能看懂水车如何保护下游田地。老匠人的经验终于离开了他的脑袋。后来管事把这次经验写进日常规矩:先看场景,再看边界,最后看失败时谁能接手。只有这些都清楚,漂亮演示才会变成可交付的工作。

坊主说,技术文档不是写给过去的,它写给下一个要维护、审查、接手和信任这套系统的人。后来坊主又规定,图纸要和水车一起更新。改了闸门却不改图,比没有图更危险;新学徒会按旧图操作,把小改动变成大事故。

揭示

这个故事讲的是:技术文档

Technical Documentation 是描述系统架构、组件、接口、数据流、权限、配置、部署、运行、故障处理和变更历史的技术材料。对企业 Agent 来说,它包括模型和工具调用边界、数据处理路径、身份权限、日志、控制点、依赖服务、风险限制、测试方法和运维流程。好的技术文档能支撑审计、客户安全评估、内部交接、事故响应和长期维护。缺少文档的系统即使能跑,也很难被企业信任和规模化采购。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 水车:企业 Agent 系统或平台
  • 老匠人的脑袋:隐性知识
  • 维修心得:零散、不完整的说明
  • 总体结构和水路图:架构、接口和数据流文档
  • 改动原因与回退办法:变更记录和运维文档
  • 验收官看懂:文档支持审计和客户评估
  • 下一个接手的人:维护者、审计员和企业买方

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

system cardmodel cardEU AI Actaudit evidencerecordkeeping