用ai做企业架构,实话实话和管理实际公司没有区别。如果不是大厂的程序员,专门做rag什么的比,常规业务赋能的技术角度,我已经拉到替代人工成本的顶了
我让我的技术中层(技术项目文档)做了很多自动化,原本计划放手让它自己做,结果在工作成果产出抽检的时候发展了很多问题。其实这个和企业架构是一样的,一个公司如果真的能脱离老板谈架构,只能是投资人参与创始人模式且要创始人经常report
否则下面小兵一定会出问题。抽检之后我就把中层的自动化停掉了。
我的技术团队文件的执行逻辑是这样的:
111入口 -> 中枢系统判断任务 -> Task Intake 做分类 -> Router 分配到正确业务模块 -> Source Map 定位真实资料和真实保存位置 -> 调用对应 skill/SOP -> 在真实业务文件夹执行 -> 必要时回流到索引/规则/Change Log
所以,111 的本质不是“多建文件”,而是“先判断,再路由,再执行,再沉淀”。
为什么文件多也不会乱
真正会让文档出问题的,不是文件数量多,而是这几件事混在一起:
规则和正文混在一个地方
素材和事实库混在一个地方
草稿和正式版混在一个地方
不知道该去哪找资料、去哪保存
改完以后没有同步记录
而你的系统刚好是反着设计的:
中枢系统 只负责导航、判断、边界和回流,不负责堆正文
写作大脑 负责“怎么写”
写作素材 负责“拿什么写”
综合材料库 和 产品资料库 是只读事实库,防止误写污染
Dora待批箱 负责待审核内容,避免半成品混进正式库
Change Log + 小抄 + Source Map 负责同步、定位和防断链
所以你这套不是“碎片化”,而是“模块化”。
文件多,在你这里反而是稳定性的来源,因为每一层都有单一职责。你不是把所有东西塞进一个总文档里,而是让每种信息待在自己该待的位置。这样后续检索、复用、审阅、纠错都会更稳。
你可以直接这样跟别人解释
“我的 111 不是靠记忆工作的,也不是把所有内容堆在一个总文件里。它是一套中枢调度系统:先判断任务类型,再路由到真实业务模块,再按规则执行,最后把变更回流到索引和日志。文件多并不等于混乱,没分类、没路由、没边界才会乱。我这里的文件多,是因为规则、素材、事实、待审核、客户跟进、技能索引都被分层管理了,所以反而更不容易出错。”
依据的核心文件在这里:
中枢系统/README.md
中枢系统/00-TASK_INTAKE_PROTOCOL.md
中枢系统/02-TASK_ROUTER.md
中枢系统/03-SOURCE_MAP.md
中枢系统/04-OUTPUT_RULES.md
中枢系统/09-CHANGE_LOG_AND_SYNC_STATUS.md
Skill 多本身不是问题,失控才是问题。我这套系统不是‘谁想到一个 skill 就直接乱用’,而是先走 111 中枢判断,再决定要不要调用 skill。也就是说,skill 在我这里不是入口,只是被中枢调度的执行工具,所以数量多不会天然把系统搞乱。”
“我解决 skill 变多风险,靠的是这几层控制:”
111 是唯一总入口。任何任务先经过中枢判断,不允许直接凭记忆或随便挑一个 skill 开始做。
skill 不是散放的。正式可复用的 skill 统一归档在 中枢系统/Codex Skills,不是到处复制一堆版本。
我有总索引,不靠脑子记。06-REUSABLE_SKILL_INDEX.md 会写清楚这个 skill 解决什么问题、什么时候调用、要读什么资料、不能越什么边界。
我有路由,不是 skill 抢活。02-TASK_ROUTER.md 先判断任务归谁,再决定是否调用 skill,所以不会因为 skill 多就互相覆盖。
我有 Source Map,先确认真实资料和真实保存位置。03-SOURCE_MAP.md 保证每个 skill 都知道该去哪读、去哪存,不会自造路径。
我有边界控制。04-OUTPUT_RULES.md 规定什么能写、什么不能承诺、什么必须我确认,所以 skill 不会乱输出。
我不允许重复膨胀。发现已有相近 skill,不是再新建一个,而是走 skill优化,优先优化旧 skill,避免越积越乱。
我有变更回流。只要 skill、新规则、路由、保存位置变了,就同步到索引、Source Map、小抄和 Change Log,不让系统靠聊天记忆运行。
“我不是用很多 skill 硬堆工作,而是用中枢系统把 skill 管起来。对我来说,skill 多不是风险,没入口、没索引、没路由、没边界才是风险。我现在做的就是把这些风险前置解决掉。”
即便我已经做到了60%以上的自动化,我用ai搭建团队的时候充分理解了一件事情就是:你的价值判断是业务的执行灵魂。
#AI工作流