AI 写代码不稀奇,把流程做成系统才值钱

现在很多人都会用 AI：写文案、改报告、做 PPT、画图、剪视频、分析文件。

这些能力当然有用，但如果把视角从个人效率拉到企业价值，就会发现一个尴尬：它们大多还是一次性输出。

今天省一点写材料的时间，明天让一页汇报更顺，后天生成一张好看的图。它们能让个人轻一点，却未必能让企业运行方式发生变化。

管理层真正能感知到的，往往不是“你用了什么 AI”，而是有没有少一个反复催办的环节，有没有少一张来回传的表，有没有让责任、状态、节点和结果沉淀下来。

01

Excel 太散，商业系统太重

很多企业不是不想数字化，而是没有那么厚的数字化条件。尤其是中小型企业，IT 能力往往偏运维：装电脑、配账号、维护现有系统可以，但要从零开发并持续迭代一套贴合业务的系统，很难。

直接买软件也不是万能解。采购、实施、培训、账号、升级、二开，都是成本。很多 SaaS 看着单价不高，一旦按人头铺开，账就很重。

更关键的是，通用软件解决的是共性问题，企业真正卡住的，往往是剩下那 10% 的贴合度。

管理不是标准件。一号管理者看全局，部门负责人看部门负荷，执行人看个人任务，负责跟进进度的人每天要知道先催谁、哪件事异常、哪件事要上报。

外部软件最容易赚钱的地方，也正是这里：标准版先把你带进去，真正要贴合组织结构、提醒规则、统计口径和管理动作时，定制、二开、升级费用才刚刚开始。

这就是中间断层：Excel 和多维表能记录，但不一定能推进；商业系统能覆盖，但常常太重、太贵、太慢。

02

有价值的小工具，先从小入口长出来

所以不要把 Vibe Coding 理解成一上来就做“大系统”。

我自己也不是这样开始的。

最早做的，往往只是一个很小的入口：行政服务反馈、办公家具领用和调拨、设备工单、周报汇总、即时激励、任务跟进。

它们看起来都不大。可能只是一个表单、一个列表、一个状态、一个提醒、一个统计页。

但只要它能进入真实流程，就不再只是“小功能”。

这就是我理解的小系统价值。

它不是把工具做得很大，而是把一个原本靠群聊、Excel、人工记忆维持的动作，变成有入口、有状态、有责任、有提醒、有留痕的流程。

以任务管理器为例，它只是我做过的很多工具中的一个，但它最能说明“表格”和“系统”的区别。

如果只是记录任务，钉钉多维表、飞书多维表当然能做。任务名称、负责人、截止时间、状态、备注，几列字段就能搭起来。

但管理层真正关心的，从来不是“有没有一张表”。而是这件事有没有被推进，异常有没有被看见，责任有没有持续落下去。

所以我的任务管理器不是让员工多填一张表，而是接进钉钉：自动获取用户信息和组织身份，任务指派后进入通知和待办；任务有时效、有完成人、有完成条件，到期前后可以自动提醒和跟催，过程进展也能持续展示。

更关键的是，它不是所有人看同一张万能表。

一号管理者看驾驶舱，掌握整体任务状态和异常分布；部门负责人看本部门事项，知道哪些任务快到期、哪些需要协调；执行人看自己的待办和完成条件；负责跟进进度的人有单独工作台，每天一早打开，就知道今天先跟谁、哪件事异常、哪条进展要审核、哪项延期要上报。

这也是通用软件最难覆盖的地方。

管理者千人千面，同样是任务管理，一号管理者、部门负责人、执行人、秘书或督办人员，关注点完全不同。市面上的模板能覆盖共性，但企业真正卡住的，往往就是剩下那 10% 的管理口径。

而很多外部软件的收费逻辑，也恰恰卡在这里：标准版看起来都有，真正要贴合你的提醒规则、统计口径、组织权限和工作台视角时，二开、实施、升级费用才刚刚开始。

所以，Vibe Coding 的价值不是让普通职场人一上来造平台。

它更像是让懂现场的人，从一个小入口开始，把企业自己的那一点特殊流程，低成本做成能跑、能改、能接入协同体系的小系统。

03

用好 Vibe Coding，先定义最小系统

很多人第一次让 AI 写系统，上来就是一句：帮我做一个任务管理平台。AI 会立刻开始写，但它也会开始猜：猜权限、字段、状态、流程、部署方式。最后出来的东西看起来完整，但一改就乱。

更稳的方法，是先写一份“小系统任务书”：它解决哪个具体问题，谁用，谁管，第一版只跑通哪条主流程，需要哪些字段，有哪些状态，谁能新增和修改，哪些操作必须留痕，最后要输出什么统计结果。

这里最重要的一项，是不做清单。第一版不做复杂审批，不做大屏，不做全公司权限，不做一切看起来高级但暂时跑不通主流程的东西。

第一版不是证明你想得多完整，而是证明这条流程真的能跑通。

04

我的默认架构：轻量，但不是裸奔

普通职场人看到 Node.js、React、TypeScript、SQLite、Knex、JWT、AES 这些词，很容易被劝退。但重点不是让你亲手掌握每个细节，而是给 AI 规定一条稳定、轻量、可维护，并且符合企业内部使用底线的开发路线。

我的默认选择是：Node.js 做后端，React + TypeScript 做前端，SQLite 做数据库，Knex 管迁移，前端打包后由后端托管；权限用 JWT，敏感信息用 AES 加密，必要时接入钉钉、飞书、企业微信。

这些技术细节，交给 AI 完全可以处理。你真正要理解的是它们为什么适合内部小系统：前后端语言体系一致，AI 好生成、好排错；TypeScript 会在编译前提示字段、类型、接口不匹配，让 AI 更早知道哪里写错；SQLite 轻量，部署和备份简单；Knex 让数据库变化有记录；后端托管前端让整个工具最终只有一个服务入口。

但企业内部工具不能只考虑“能不能跑”，还要考虑“谁能看、谁能改、谁能发、谁能查”。一号管理者、部门负责人、执行人、督办人员看到的内容不同，背后就必须有清晰的身份识别和权限边界。

所以我会把JWT 和 AES放进默认架构里。JWT 负责登录态和接口鉴权，系统要知道“你是谁、你是什么角色、你能访问什么接口”。AES 负责敏感信息保护，比如第三方平台凭证、用户身份映射、部分业务敏感字段，不能直接裸露在数据库和日志里。

这些安全动作听起来专业，但只要规则说清楚，AI 可以完成：登录后签发 JWT、接口中间件校验角色、敏感字段 AES 加密、密钥走环境变量、日志不打印 token 和 secret、新增接口说明权限边界。

安全策略由人定，具体实现交给 AI。普通职场人不需要从零手写每一个加密函数和鉴权中间件，但必须知道：一个能进入企业流程的小系统，不能只会跑，还要可控地跑、安全地跑。

如果再配合组件化和原子化，把按钮、表单、列表、接口、状态、数据表、权限校验拆清楚，AI 后期升级时就不容易牵一发动全身。

05

给 AI 标准化技能，不要只靠聊天

Vibe Coding 最怕每次从头解释。今天说一次技术栈，明天说一次目录结构，换个会话又全部重来，AI 只能临时猜。

所以项目里要有规则文件，比如 CLAUDE.md、AGENTS.md 或 PROJECT_RULES.md。里面写清楚固定技术栈、目录结构、接口返回格式、数据库迁移方式、哪些文件不能乱改、修改前必须说明影响范围、大改动先给方案、完成后必须自检。

我也建议使用Superpower这类技能包，把开发和调试动作标准化。遇到 Bug 怎么排查，接口问题怎么验证，构建失败怎么定位，改完代码怎么自检，提交前怎么审查影响范围，都不要每次靠你临时提醒。

在日常内部工具开发里，这类技能包足以覆盖90% 左右的开发和调试任务。你负责业务判断和验收标准，Skill 负责让 AI 在写代码、查问题、改 Bug 时少走弯路。

落到执行，可以压缩成四步。

验收时也不要只看页面能不能打开。要看能不能新增数据、编辑数据、流转状态、触发提醒、保留记录、生成统计、换台机器还能部署、出问题能不能回滚。

页面能打开，只是 Demo；数据能闭环，才开始像工具。

未来很多岗位的差距，不只是会不会用 AI，而是能不能看懂一个流程，定义它的角色、状态、规则和边界，再用 AI 把它变成可运行、可维护、可升级的系统。

AI 写一份 PPT，可能让一次汇报更顺。

但一个真正跑进流程的小系统，会让某个环节长期更便宜、更清楚、更可控。这才是管理层真正看得见的 AI 价值：不是一次漂亮输出，而是一种可复用的组织能力。