公民开发并非万能，它只是“草稿式开发” 5/7
引言
在第4回我们确认过，那些没有被编码的资产终将变成未来的负遗产。 因此值得重新追问：公民开发真的是打造生产系统的手段吗？
结论是否定的。公民开发并不承担正式环境。 它的本质是把用户视角下的需求定义转化为“能跑起来的草稿”。
一旦忽略这个视角，把“公民开发 = 任何人立刻就能造系统的魔法工具”混为一谈，就会像历史上那样再次大量制造负遗产。 让我们来梳理“草稿式开发”意味着什么，以及应当如何善用它。
全系列索引
- 洞察公民开发的未来──历史・当下・生成式 AI・以及更远的前方 0/7
- 公民开发是 EUC 的回归吗？──神 Excel 留下的历史教训 1/7
- 神 Excel 真的是反派吗？──从救世主到负遗产 2/7
- 现代公民开发平台的光与影 3/7
- 生成式 AI 会拯救哪些遗产，又会放弃哪些遗产 4/7
- 公民开发并非万能，它只是“草稿式开发” 5/7 (本篇)
- 视角错位如何批量制造负遗产 6/7
- 负遗产仍会不断诞生，但仍可驯服──公民开发的未来图景 7/7
草稿式开发的价值何在
由一线通过公民开发打造的应用或工具，常被视为“不完整”“很粗糙”。 但恰恰是这种“粗糙”构成了它的价值。
用户视角的需求浮出水面
想象一下，销售部门用低代码平台搭建了一款客户管理应用。 其中凝结着一线每天体会到的“如果不是这样就会很不方便”的直觉。
- 输入字段需要多细的颗粒度
- 列表画面里想摆出哪些信息
- 按钮如何摆放、流程是否顺手
这些都无法靠一份“需求说明书”传达。 即使写成文字，现场所需的细腻感受与“工作的手感”几乎都会流失。 只有当草稿能实际运行时，才能得到“这样就能用”“现实中还是不顺手”的真实反馈。
更早发现误解与缺漏
此外，只要有一个在跑的草稿， “这里没有搜索功能会很麻烦”、 “审批流程应该是两级而不是三级” 这样的误解或遗漏就能在早期被发现。
过去的系统开发，大多依赖专家阅读需求文档后凭想象来设计。 结果一上线，现场便抱怨“与设想完全不同”，返工成了常态。 公民开发能够成为削减这种无谓返工的有力武器。
将草稿直接投入生产的陷阱
然而绝不能把草稿原封不动地投入正式环境。 其中潜伏着巨大的陷阱。
- 可扩展性：在小部门运行无碍，但一旦全公司部署就会立刻遇到性能瓶颈。
- 安全性：访问控制和日志管理薄弱，经不起审计与合规检查。
- 可维护性：知识高度个人化，一旦作者调离或离职就会成了黑箱。
“草稿有价值”与“草稿可以直接上生产”完全是两回事。 否则只会重演神 Excel 曾经从救世主滑向负遗产的剧本。
与专业团队的分工
那么公民开发的成果该如何处理？答案非常明确。
- 公民 = 负责绘制草稿：把用户视角具体化，给出原型。
- 专业人士 = 负责誊写定稿：在扩展性、安全性、可维护性等非功能需求上重新搭建。
贯彻这种分工能让双方都发挥最大优势。 公民能把“现场的真实手感”直接落实在工具里。 专业人士则通过清稿来保证质量与持续性。
传统开发往往是在“只靠需求书凭想象设计”。 有了草稿，讨论从一开始就能达到更高的清晰度。 由此开发效率得以提升，成果质量也同步提高。
治理应该守住什么
若要健康地运用公民开发，组织必须建立明确的规则。
- 明确化：规定“公民开发的成果仅限于原型，使用范围也要限定”。
- 盘点：设立流程，定期整理和淘汰被放置的应用或 RPA。
- 迁移流程：凡是有价值的草稿都必须移交 IT 部门，经过清稿后再进入正式环境。
完善的治理可以大幅降低重蹈神 Excel 负遗产的风险。 反之，一旦缺乏这些规则，公民开发就会沦为“野生应用制造机”，只会让技术债越滚越大。
总结
公民开发并非“让任何人都能搭建生产系统的万能机制”。 但如果把它当作“草稿”来用，就能减少需求定义中的误解与缺漏，让系统设计充分反映用户视角。
正式系统交给专业人士，草稿由公民来描绘。 彻底执行这份分工，就能让公民开发成为提升未来生产力的起点，而不是新的负遗产。
公民开发的真正意义，在于“让需求定义流程走向民主化”。 只有理解这一点，它才能成为组织的可持续力量。