我于2006年创立了Software Tailor。十九年间，公司经历了四个不同的经济周期，服务了六家财富全球500强客户，涵盖制药、金融、政府、法律、国防和能源领域，自2007年以来项目零失败。最后这个数字是投资者和采购评审最常问及的，也是唯一需要解释的。以下是支撑这一纪录的四条工程规则。
规则一：单一交付模式，无服务与产品模糊
每个Software Tailor项目都采用相同的交付模式——一个范围严格限定的试点阶段，交付可运行的软件，随后客户根据交付成果自主决定是否扩展。我们没有单独的“服务”部门按需求文档交付，也没有单独的“产品”部门按路线图交付。两者会产生冲突，一方总会补贴另一方。
单一模式意味着每位工程师在开始前都清楚“完成”的标准。这是避免失败的前提。
规则二：客户群体纪律——只服务我们能交付的客户
我们的客户群是经过筛选的，而非机会主义。19年服务六家财富全球500强客户，不是销售缓慢，而是有意设定的门槛。每个客户在启动前必须通过三项测试：他们的问题是我们曾解决过的；他们的内部赞助人是软件的最终用户（而非中间层）；他们的硬件/数据环境允许我们交付，无需六个月的采购延误。
未通过任一测试的客户会被推荐给其他人，而非启动项目。这条规则最常导致我们放弃收入，也是19年来零例外的规则。
规则三：工程纪律对应公认框架
早在AI风险管理拥有专门框架之前，我为Software Tailor制定的工程规则已与其模式相符：管理工作、识别风险、衡量结果、管理变更。NIST AI RMF 1.0于2023年正式确立了该模式，2026年4月的关键基础设施配置文件将其扩展至受监管行业。阅读这些文件，我们的内部纪律与四大功能完美对应。
这带来的好处是：每个项目都可依据外部框架进行端到端审计，而非仅凭自身习惯。当采购团队询问试点阶段范围如何确定时，答案与NIST风险管理的回答一致，且客户自身的合规团队已内化该表达。
规则四：可记录、可恢复、可重现
第四条规则早于我们现用于AI Suite的审计轨迹术语。每个Software Tailor项目均处于一种状态，任何决策、任何工件、任何代码版本均可从版本控制的输入中重现。这在软件工程中并不罕见；不同寻常的是我们将其应用于 项目，不仅仅是代码库。冲刺决策、范围变更、客户签字——全部记录，全部可恢复。
这种纪律正是我们 无内容审计日志 方法能够让 AI Suite 如此发布的原因。审计行模式是我们已经应用于项目的相同模式。词汇借鉴自合规框架；实践借鉴自我们的交付方式。
延续到 AI Suite 的
本地 AI Suite + AI Admin Console 系列——见 为什么我们发布 AI 作为可安装的二进制文件，而非云端 SaaS ——是将相同的工程纪律应用于产品线，而非定制项目。相同的单一交付模式（桌面安装程序，附带免费一周试用），相同的客户群体纪律（受监管行业，具有明确的数据驻留限制），相同的框架映射（NIST AI RMF + 欧盟 AI 法案部署者义务），相同的可记录-可恢复-可重建的审计态势。
自 2007 年以来零项目失败不是口号。这是少数规则无一例外应用的结果。相同的规则现在管理着 AI Suite 的构建。
参考文献
- NIST。“人工智能风险管理框架（AI RMF 1.0）。” https://www.nist.gov/itl/ai-risk-management-framework。访问日期 2026-07-15。