从第一个项目，长出企业自己的 Flowness 工作方法

企业用 AI 做完一个项目后，下一个项目仍可能从头解释需求、重做选型、再次发现相似的问题。代码留下来了，决定代码为什么这样写的依据却散在聊天里。Flowness 的一条成长路径，是在交付当前业务成果的同时，把这些判断整理成下一次能够使用、也能够质疑的方法。

Flowness 是 ToWow 用来组织 AI 工作的一种 Harness，包含流程、上下文、技能和检查工具。企业自己的方法不必在开工前完整设计出来。它可以从一项真实需求开始，只接入眼下需要的部分；项目推进时，再把反复出现的判断和异常沉淀下来。

用一个内部资料申请页作方法示例：员工提出申请，负责人审阅，必要时退回补充，通过后才能查看资料。它看起来只是几个页面，却已经包含对象、权限、状态和失败路径。若只让 AI 生成界面，演示可以很快出现；到了验收，谁能查看什么、退回后怎样继续，仍可能没有答案。

把起步放在实际需求上，就可以按需要逐个引入已有模块，初期保持较低复杂度，在开发中沉淀技能、规范与模板。需求、设计、工程方案和执行规划各有作用。需求说明要解决的业务问题；设计确定对象与关系；工程方案再解释数据流、接口和技术选择，执行规划把它们变成可做的工作。

申请页未必一开始就需要复杂编排。先把一次申请亲手跑通，便能看出哪些约束真的参与交付：申请对象与资料对象如何关联，审阅人能否更换，拒绝与退回是否同义，什么状态算完成。若审批只在单人演示里成立，引入更多自动化也不会补出缺失的业务定义。必要流程的选择，应当由这些具体问题推动。

现有流程模板能减少遗漏，已有技能能提供调查、设计或审阅的入口。它们也有成本：每增加一个环节，就多一份要维护的上下文和完成判据。例如，申请规则还在变化时，可以先加强调查与设计；等重复的检查动作稳定下来，再把它接入自动执行。先在项目里看到缺口，再决定补哪一段流程，能让团队解释这个环节为什么存在。按需采用流程是一项组织原则，不等于现有安装命令已经支持任意裁剪整套模块。

申请页的业务产物，是页面、接口、数据结构和验收结果。另一类产物是可复用的依据：为什么选择这个存储方式，申请与审阅记录是什么关系，退回后的生命周期怎样继续，什么证据足以判定访问控制有效。这些记录帮助下一位开发者理解取舍，也让当前项目的审阅有据可查。

要让审阅能够追溯，就需要保留选型理由与模块关系。常见审阅问题可以提炼为检查依据，设计记录则要包含对象关系、生命周期、成功标准、候选方案取舍和需求覆盖。在申请页中，一条“权限还不清楚”的修改意见，经过调查后可以成为更具体的检查：接口是否在服务端核对申请人，审阅通过是否只授予对应资料的访问权，退回是否撤销既有授权。

从修改意见到检查项，中间不能省掉调查。原始意见记录某次不满意，问题卡把它收束为可以调查的对象，设计决定解释解决办法，检查项才规定以后怎样发现同类缺口。沿着这条路，使用中形成的流程、环境、文档与技能，便有了具体的整理对象。把修改判断和异常处理的理由留下来，下一次调用方法时，才能知道它准备解决什么问题。

因此，复用的对象有不同成熟度。一次选型理由可以先留在项目里；多次遇到的检查问题可以进入模板；操作顺序稳定、输入与完成标准清楚的部分，才适合成为技能。过早抽象会把偶然约束推广到所有项目，迟迟不整理则让同一判断反复发生。判断记录保留具体情境，使团队以后能够重新决定它应当属于哪一层。

方法有了可复用形态，更新便成为下一道工程问题。两个项目可以使用相同的设计技能，却不能共享同一份任务账本。资料申请页的审批记录、权限配置和项目判断属于它自己；共享技能修订后，这些事实仍然需要连续保存。

当前分发实现把这条边界落在写入路径上。执行程序有自己的安装与更新方式，文件同步搬运技能、工作入口和运行时胶水。胶水负责把共同的工作方法接到具体 AI 运行环境，例如怎样加载规约、进入任务流程、触发工具调用前的检查。换运行时，需要逐项核对这些连接处，不能因核心逻辑可复用就推定入口和拦截也已经等价。

同步函数更新共享目录，不构造项目私有状态的写入路径。相应测试为两个临时项目写入不同状态，记录私有目录的路径与内容哈希，修改共享入口后执行同步，再断言私有哈希不变、共享入口已经更新。项目自有的 CLAUDE.md 和 AGENTS.md 也受到保护；带系统管理标记的通用版规约则可以刷新。文件的位置与管理归属需要一起判断。

这里的分发是同一台机器上不同项目目录之间的文件同步。技能的知识依赖也需要核对：现有组装逻辑检查声明必需的知识文件，缺失时返回失败。复制一个技能目录，与为下一次工作准备好它需要的依据，是两件相连但不同的工作。

保存了文档，仍可能做不出想要的效果。9 月 29 日的讨论修订了原先偏工程方案的推进方式，转向更多动手做 Demo：只给一个框架让 AI 生成，效果有限；先评价可见作品，留下具体修改判断，再从聊天整理需求与设计，重新实现。这个变化让方法接受实际作品的检验。

申请页的 Demo 可以暴露文字里不易察觉的问题。审阅人打开页面，看不到申请原因，便无法作出决定；退回后员工找不到补充入口，生命周期就断了。评价不能只留一句“体验不好”。它需要返回需求：审阅人作决定前必须看见哪些信息；再返回设计：补充材料归属于原申请还是新申请，退回状态允许哪些动作。

随后重做 Demo，按照场景验收，再更新持久文档。这使修改意见成为下一轮实现的共同上下文，避免同一句要求只停留在某次聊天中。文字和 Demo 可以是两个起点：业务关系已经清楚时，文字先行；交互判断尚模糊时，作品帮助提问。它们最终都需要形成更清楚的需求、设计和验收依据。

问题卡为这种迭代提供了一个轻量入口：聊天中提出的问题先进入卡片，调查形成方案，再汇入统一设计。由此形成的设计、架构和决策基线交给下一轮实现，场景验收再检查这些决定是否解决了原来的问题。问题仍在，就带着实际表现回到调查与设计。

第二个项目若改成设备借用申请，可以复用申请对象、状态检查和服务端权限审阅的方法。它还会带来新的问题：设备有库存与归还期限，批准不一定意味着立即可领取。把资料申请页的状态模型直接复制过去，反而可能掩盖差异。旧判断记录在此发挥作用：团队能读到原来为什么采用那组状态，再判断哪些前提已经变化。

复用时，团队可以先把旧检查项带入新项目的审阅，再逐项写出适用理由。服务端核对操作者身份的要求可能继续成立，批准后立即开放访问的规则却需要改写。两者若被封装在同一个技能里，就需要拆开稳定的检查动作与业务特定的状态判断。这样的修订会增加维护工作，却也让复用依据更清楚：以后调用技能时，能够知道它检查了什么，以及哪些决定仍须由项目作出。

企业的方法便在这种复用与修订中逐步形成。交付留下业务成果，审阅留下判断，调查把判断变成依据，共享工具承载其中稳定的部分。下一项目重新确认适用条件，并将新的失败补回方法。衡量这条路径，需要看具体成果：设计取舍是否可追溯，检查依据是否被实际使用，共享更新是否守住项目事实，复用后是否仍通过场景验收。

本文来自我们在 8—9 月陪跑中的设计讨论和方法调整。