自 2007 年以来零项目失败 —— 背后的工程纪律
我于 2006 年创立 Software Tailor。十九年过去,公司穿越了四个不同的经济周期,服务过来自医药、金融、政府、法律、国防与能源行业的六家 Fortune Global 500 客户,自 2007 年以来零项目失败。最后这一数字,是投资人和采购审查人最常问起的,也是唯一需要解释的。以下是托起这一纪录的四条工程纪律。
纪律一:统一的交付模式,服务与产品之间没有模糊地带
Software Tailor 的每一次合作都运行在同一交付模式之上 —— 一个范围严格界定的试点阶段交付可工作的软件,随后由客户基于已交付的内容选择是否资助扩展。我们不另设一套依据需求文档交付的「服务」业务、再另设一套依据路线图交付的「产品」业务。两者会冲突;总有一方在交叉补贴另一方。
统一的模式意味着每一位工程师在开工前就知道「完成」长什么样。这是不失败的前置条件。
纪律二:客户群体纪律 —— 只接我们能交付的客户
我们的客户群体是经过选择的 —— 而非机会主义的。十九年中六家 Fortune Global 500 客户,不是缓慢的销售管道,而是刻意的筛选门槛。我们承接的每一位客户都必须在启动前通过三项测试:他们的问题是我们曾解决过的;他们的内部赞助人就是将使用该软件的人(而非中间层);他们的硬件与数据环境允许我们在不绕入六个月采购弯路的情况下交付。
未能通过其中任何一项测试的客户,会被转介给他人,而非成为一个项目。这是最常让我们损失营收的一条规则,也是十九年来零例外的一条。
纪律三:工程纪律对应到一个被认可的框架
早在 AI 风险管理拥有自己的框架之前,我为 Software Tailor 编订的工程规则就与同一种形态模式吻合:治理工作、映射风险、衡量结果、管理变更。NIST AI RMF 1.0 [1] 于 2023 年为 AI 形式化了这一模式,而 2026 年 4 月的关键基础设施 profile [1] 将其延伸至受监管行业。读着这些文件,我们的内部纪律干净地映射到四项职能。
这给我们什么:每一个项目都可端到端依据一个外部框架被审计,而非仅按我们自家的习惯。当采购团队问起试点阶段的范围是如何确定的,答案与 NIST 关于风险管理的回答相同 —— 而客户自身的合规团队早已内化了这套语汇。
纪律四:可记录、可恢复、可重建
第四条规则早于我们如今用于 AI Suite 的审计轨迹语汇。Software Tailor 的每一次合作都运行在这样的状态:任何决策、任何制品、任何版本的代码,都可由置于版本控制下的输入重新构建。这对软件工程而言一般也并不少见;少见之处在于,我们将其应用于项目本身,而不仅是代码库。冲刺决策、范围变更、客户签收 —— 全部记录,全部可恢复。
正是这一纪律,使我们在 AI Suite 上的 无内容审计日志方法以其当下的形态交付。审计行的模式,正是我们早已应用于项目的同一种模式。语汇借自合规框架;实践借自我们交付的方式。
什么延续到了 AI Suite
Local AI Suite + AI Admin Console 这条产品线 — 见我们为何以可安装的二进制文件交付 AI,而非云端 SaaS — 正是把同一套工程纪律应用于产品线,而非一次定制合作。同样的单一交付模式(由客户在自有环境中运行的桌面安装程序),同样的客户群体纪律(有明确数据驻留约束的受监管行业),同样的框架映射(NIST AI RMF + EU AI Act 部署者义务),同样的可记录、可恢复、可重建的审计姿态。
自 2007 年以来零项目失败并非口号。它是不设例外地应用一小撮规则的结果。同一套规则,如今也治理着 AI Suite 的构建方式。
参考资料
- NIST. "AI Risk Management Framework (AI RMF 1.0)." nist.gov/itl/ai-risk-management-framework. 访问于 2026-07-15。
相关文章
在真实工作负载上检验同一套纪律。
本地 AI 平台建立在缔造这一纪录的同一套规则之上 — 可记录、可恢复、可重建,一概不作例外。在您自己的环境中把它部署到一项真实工作负载上,并以同样的标准要求它。