30 天完成企业氛围编程试点

企业氛围编程试点应证明，团队能在接近生产环境的条件下运行、检查、恢复并离开该平台。快速生成一个好看的应用很有用，但它回答的是评估中成本最低的问题。

合同应以源代码导出、访问控制、数据位置、部署、回滚、审计记录和开发者交接的通过或失败记录为依据。如果供应商控制测试、对模糊结果作辩解，或在最终演练中补上缺失步骤，试点衡量的就是供应商协助能力，而不是企业就绪程度。

试点既衡量构建速度，也衡量退出成本

试点需要在任何人开始构建前冻结验收计划。否则，每个棘手的结果都会变成要求更多时间、更狭窄的解释，或承诺下一版本会解决。

选择一个参考应用，它应足够小，能按时完成，也要足够复杂，能暴露运营风险。它应包含多个用户角色、租户边界、持久化记录、文件处理、外部服务、后台任务、密钥，以及至少一次数据库迁移。宣传网站几乎无法证明一个企业应用平台的能力。

将每项测试记录在平台外保存的证据文件中。简单的结构可让结果便于审查：

pilot:
  application: claims-intake-reference
  revision: 8f21c6a
  test_owner: enterprise-architecture
  vendor_observer: true
controls:
  source_export:
    result: pending
    evidence: []
    blocker_if_failed: true
  access_control:
    result: pending
    evidence: []
    blocker_if_failed: true
  data_location:
    result: pending
    evidence: []
    blocker_if_failed: true
exceptions:
  owner: procurement
  expires: 2026-09-30
  compensating_control: null

版本号标识正在测试的准确应用。每条证据都应指向由你的团队控制的材料，例如导出归档、终端记录、日志文件、身份配置、恢复耗时或供应商签署回复。截图可以支持结论，却很少能独自证明结论，因为它们没有请求、响应代码、配置历史和前后状态。

将门槛与偏好分开。可移植性、租户隔离、可恢复性、数据位置和审计完整性通常属于门槛。编辑器便利性和生成速度会影响采用，但高分不能抵消隔离测试的失败。把所有结果平均成一个看似喜人的分数，是采购中常见的错误，因为十项表面通过足以掩盖一项危险失败。

为每项控制指定一名企业负责人，并指定一名能宣布失败的人。供应商可以观察并纠正事实错误，但不应给自己的工作打分。记录供应商提供的任何协助。若供应商人员修复导出、修改策略或执行回滚，应在没有他们参与的情况下重做测试后，才能判定通过。

只要团队持续测试证据，30 天的安排就能奏效。尽早冻结范围并构建参考应用，然后为破坏性测试、干净环境重建、身份故障、恢复演练和交接预留足够时间。一直开发到第 28 天的团队，往往会在最后一次会议上讨论那些从未测试过的功能。

源代码导出必须能独立构建

只有企业能在干净环境中，在没有平台访问权限的情况下构建、测试、运行和修改应用，源代码导出才算通过。拥有一个装满代码的目录，不等于拥有可移植的应用。

导出一个固定版本，记录其校验和，并将其转移到由企业控制的新代码仓库。使用没有供应商 Cookie、命令凭据、包缓存、生成文件或隐藏环境变量的干净机器或一次性构建工作机。接收代码的开发者应只有导出内容及其文档。

运行仓库声明的命令，而不是会议中临时提供的命令。对于 React 和 Go 应用，记录可能如下：

$ npm ci
added 428 packages, and audited 429 packages
$ npm test
Test Suites: 18 passed, 18 total
$ go test ./...
ok   example/api/auth
ok   example/api/orders
$ go build ./cmd/server
$ ./server
configuration error: DATABASE_URL is required

最后这个错误是有价值的通过证据，不是尴尬。它证明程序会指出缺失依赖，而不是悄悄连接到供应商服务。补齐文档中说明的配置后，团队应启动应用、执行迁移、创建用户、通过测试替身调用外部集成，并运行自动化测试。

《十二要素应用》指出，应用应在版本控制中跟踪一个代码库，并明确声明依赖。这些原则依然有用，但不能仅凭它们断定可移植性。生成的应用可能声明了公开依赖，却仍依赖专有身份代理、部署元数据、托管函数、构建插件或运行时端点。测试必须找出这些依赖，并判断哪些可替换。

检查导出内容中的源映射、生成的客户端、迁移文件、测试夹具、构建定义、许可证声明、基础设施配置和依赖锁定文件。搜索硬编码服务地址、不透明的二进制组件、被复制的密钥，以及只能在平台内部解析的导入。团队还必须了解合同终止后，对哪些产物仍有使用权。技术上拿到了文件，无法弥补权利缺失。

数据库可移植性应在此门槛内单独检查。PostgreSQL 文档说明，pg_dump 可导出一个数据库并生成一致性快照，但不会导出角色等集群级对象。仅恢复应用数据库的团队，可能发现所有权和权限假设都消失了。测试创建数据库结构、种子数据、重建角色、扩展，以及恢复到由企业控制的 PostgreSQL 实例。

当一名不熟悉该应用的开发者能根据书面说明，从导出内容复现运行中的系统，并替换每项供应商运行时依赖或确定已接受的替代方案时，即为通过。若文件缺失、构建调用私有服务、数据库结构历史无法重建数据库、归档中出现密钥，或必须由供应商介入，则为失败。路线图中未来可能提供的导出功能不会改变结论。

访问控制必须经得起直接请求

只有当服务端拒绝每一项未授权操作，即使用户绕过生成的界面，访问控制才算通过。隐藏按钮、路由或菜单项测试的是展示，不是授权。

在生成应用前定义角色和资源。使用包含租户边界和敏感操作的小型权限矩阵：

通过浏览器和直接调用 API 两种方式执行每项拒绝测试。修改对象标识符、租户标识符、查询筛选条件和请求正文。单独尝试批量端点，因为团队经常保护单条记录路径，却遗漏导出、搜索、附件和批量更新路由。确认客户端变更移除所有可见限制后，服务端仍会强制执行授权。

OWASP 应用安全验证标准 4.0 将访问控制验证放在可信服务层，并要求默认拒绝访问。这一点对生成式系统尤其重要，因为精美的界面会带来虚假的安全感。我见过团队接受了一个角色演示，受限用户没有编辑按钮，随后却发现同一用户可以手动提交编辑请求。

身份验证和授权需要分别作出结论。身份验证确定谁出示了凭据。授权决定该身份此刻是否可以对这个对象执行此操作。单点登录可以通过，而对象授权可能在所有租户之间都失败。

连接企业身份提供商，测试入职、调岗和离职场景。创建用户，修改用户所属组，移除高权限角色，禁用账户，并撤销活跃会话。测量每项变更影响应用所需的时间。测试紧急本地账户、服务身份、API 凭据和平台管理员，不要只限于普通应用用户。

OpenID Connect Core 将 sub 声明定义为在签发方内部唯一且永不重新分配的标识符。应将这个稳定标识符与易读的登录名一并存储和审计。电子邮件地址和显示名称会变化，只用它们可能损坏所有权历史，或在账户重新使用后让两个不同的人看似相同。

如果任一低权限用户能跨越租户边界，如果管理访问绕过已记录的审批，如果被移除的权限在约定时限后仍然有效，或团队无法解释谁可以访问生产数据，就应判定该门槛失败。供应商管理员也是一个访问路径，即使访问是通过支持工具而非应用本身进行。

数据位置需要组件级地图

只有当团队能说明每一份重要副本、处理方、传输、备份和支持路径时，数据位置才算通过。为应用工作负载选择一个国家，只能证明该工作负载的位置，不能证明所有相关数据的位置。

从数据类别开始，而不是笼统地问数据驻留问题。包括客户记录、上传文件、凭据、提示词、生成的源代码、平台元数据、日志、追踪信息、模型请求和响应、备份、支持附件及分析数据。对每个类别，记录其进入位置、存放位置、由哪个服务处理、如何流动、保留多久以及谁能访问。

这种区分能发现一个常见错误：数据驻留、数据处理位置和传输控制彼此相关，但不是同一项主张。数据库可能驻留在一个国家，而模型推理、遥测分析、支持访问或灾难恢复可能在其他地方产生传输。采购材料若只说数据在某区域「托管」，通常没有回答这些路径。

为每个类别使用一个预置标记，例如唯一的项目字符串或合成记录标识符。要求供应商展示该标记可能出现在应用存储、运营日志、备份、支持系统和模型处理中的位置。在法务和安全审查人员接受这份地图之前，不要在试点中放入真实个人数据或受监管数据。

索取有关子处理方、处理区域、支持访问、保留、删除、加密所有权和灾难恢复的书面证据。销售电话中的口头保证应保持为待解决事项。如果平台使用多家模型提供商，应确定企业能否选择或限制它们、每家在哪里处理请求，以及提示词或输出是否会被提供商保留。

将删除作为可观察的流程来测试。删除一条预置记录，然后询问活跃存储、日志、快照、备份和导出的审计材料中还保留什么。立即从每个备份中删除未必可行，也未必合适，但提供商应准确说明保留期限和最终到期行为。法务团队决定这种行为是否符合义务，试点团队负责记录实际发生的情况。

当数据地图足以让安全、隐私和法务审查人员批准每条路径，且配置与已记录的位置一致时，即为通过。如果提供商只回答主数据库位置、无法识别模型处理地点、允许无法解释的支持访问，或将备份地理位置视为保密信息，则为失败。未解决的位置，不是可接受位置的证据。

部署必须能脱离单个浏览器会话重复执行

当团队能通过有文档、可重复的流程发布一个固定版本，并准确证明各环境实际部署了什么时，部署才算通过。一个成功的预览 URL 不能证明发布控制。

创建独立的测试环境和类生产环境，它们要有不同的身份、密钥、数据库、域名和审批规则。同一源代码版本应能在二者之间流动，无需复制隐藏的编辑器状态。配置可以不同，但差异必须被声明且可审查。

从干净状态两次部署同一版本。记录源代码版本、依赖锁定校验和、构建结果、迁移版本、配置引用、审批人、部署人、开始和结束时间、目标环境、健康检查结果和最终发布标识符。然后比较记录。如果相同输入产生明显不同的软件，团队必须在投入生产前得到解释。

发布记录可以采用这种简洁结构：

{
  "release_id": "rel-1042",
  "source_revision": "8f21c6a",
  "environment": "pilot-prod",
  "schema_version": "20260728_03",
  "requested_by": "oidc:00u81c",
  "approved_by": "oidc:00u19a",
  "result": "succeeded",
  "health_check": "passed"
}

故意让部署失败。移除必需密钥、破坏迁移、拒绝访问外部服务，并让健康检查失败。系统应安全停止，说明在哪个阶段失败，保留诊断证据，并避免把部分发布显示为健康。部署界面若只报告「失败」，会让操作人员在事故期间无从判断。

如果策略要求，测试职责分离。修改生产代码的人不应悄悄给自己审批，或修改审计记录。还应确定平台管理员、生成应用管理员和云运营人员是否拥有不同权限。这些角色在演示中常被合并，因为所有内容都由一个账户创建。

当另一名获授权的操作人员能部署选定版本、查看其配置引用、识别审批记录并在没有供应商帮助的情况下确认其健康状态时，即为通过。若部署依赖最初的聊天会话、未命名的最新版本、个人凭据、可变的生成产物或未记录的人工操作，则为失败。

回滚必须涵盖代码、数据库结构、数据和副作用

当回滚能在约定时间内恢复到已定义的服务状态，并将数据损失控制在约定范围内时，才算通过。如果数据库或外部副作用已向前推进，仅回退应用代码可能使事故更严重。

在演练前设定恢复时间目标和恢复点目标。恢复时间衡量服务可中断多久。恢复点衡量业务可以损失多少已提交数据。团队常说「回滚花了六分钟」，却没检查最近的记录是否消失，这只报告了一半结果。

使用一个刻意不兼容的版本。版本 A 将客户状态存为文本。版本 B 将其迁移到新表、修改 API、通过测试服务发出通知，并启动后台转换。在发布前、发布中和发布后添加记录，然后中断转换并触发回滚。

第一次故障通常发生在版本 A 针对版本 B 的数据库结构启动时。旧代码预期一个已被迁移删除的列。因此，仅恢复应用会造成第二次中断。恢复数据库快照可能让版本 A 重新运行，却可能丢弃快照后提交的记录。重放这些记录可能重复发送外部通知，除非集成使用幂等机制。

团队必须选择恢复设计，不能假定一种方法适用于所有发布。兼容的扩展和收缩迁移可以让新旧代码针对同一数据库结构运行。在不可逆的数据转换后，向前修复可能比回退更安全。当业务接受其恢复点且团队已测试重放时，快照恢复可以奏效。记录每类迁移适用的方法。

演练期间，记录发现时间、决策时间、操作人员、审批、应用版本、数据库结构版本、快照标识、已恢复记录、丢失记录、重放结果、排队任务和外部调用。技术健康检查通过后，还要验证业务行为。绿色的进程监控并不能证明权限、余额、附件或工作流状态仍然正确。

当操作人员无需供应商介入就能执行文档化恢复路径，满足两个恢复目标、对账记录并解释每个外部副作用时，即为通过。若回滚只是一个未说明含义的按钮、数据库结构兼容性未知、快照无法恢复到隔离环境，或团队无法计算数据损失，则为失败。

审计记录必须能还原有争议的操作

当调查人员能确定谁在何时、从何处、以何种权限对哪个对象做了什么，以及结果如何时，审计能力才算通过。为项目协作设计的按时间排列活动流，不一定是审计记录。

NIST SP 800-53 第 5 版在 AC-2 中将账户管理与 AU 控制项中的事件日志和审计记录生成分开。这种划分合理。身份管理决定哪个主体拥有访问权，审计生成记录该主体如何使用权限。调查有争议的部署或数据导出时，两类历史都不可少。

NIST AU-3 要求记录包含事件类型、时间、地点、来源、结果和关联身份。对于本试点，还应在适用时加入租户、目标对象、请求关联、变更前后与安全相关的值、身份验证上下文和审批引用。不要为了让日志显得完整而记录密钥值、会话令牌、包含受限数据的完整提示词或敏感记录正文。

有用的事件应类似这样：

{
  "event": "role.assignment.changed",
  "time": "2026-07-28T14:03:22Z",
  "actor_sub": "oidc:00u81c",
  "actor_role": "platform-admin",
  "tenant": "tenant-204",
  "target": "user-771",
  "change": {"from": "viewer", "to": "manager"},
  "outcome": "success",
  "request_id": "req-9918",
  "approval_id": "apr-118"
}

为身份验证失败、角色变更、会话撤销、密钥访问、源代码导出、数据导出、配置变更、部署、回滚、快照使用、域名变更、支持访问、审计导出和审计设置变更生成事件。既测试失败尝试，也测试成功操作。调查人员经常需要那次成功权限变更之前的拒绝记录。

变更用户显示名称和电子邮件，然后确认早期事件仍关联到稳定身份。通过共同的请求或会话引用，比对平台事件、应用事件和身份提供商记录。检查时钟一致性，因为五分钟的偏差就能颠倒审批与部署看似发生的顺序。

用试点中权限最高的角色尝试篡改、删除、禁用审计流，或使其溢出。验证保留期限、导出格式、分页、时区、筛选条件及记录变得可搜索前的延迟。将记录导出到企业控制的存储中，并确认导出包含适合调查的稳定字段名。可下载的电子表格能帮助分析人员，但如果单元格截断结构化值，它不应是唯一格式。

当未参与测试的审查人员能根据导出的证据还原一次预置事故，并发现削弱日志记录的尝试时，即为通过。如果管理员能抹除自己的痕迹、身份无法关联、失败操作消失、支持活动不可见，或保留期限取决于未记录的套餐层级，则为失败。

开发者交接会暴露隐藏的平台依赖

当未构建试点的开发者无需原始构建者或平台，就能维护和发布导出的应用时，开发者交接才算通过。代码可读性很重要，但成功的所有权转移是更有力的测试。

向接收代码的开发者提供干净环境、源代码导出、架构说明、配置引用、数据模型、迁移历史、测试说明、部署流程、恢复流程、依赖清单和已知限制。在演练期间移除平台访问权限。原始构建者可以观察，但在记录时间和阻塞项之前不应回答实现问题。

预置一个普通缺陷，例如报告查询中缺少租户筛选条件。要求开发者复现问题、找到授权路径、添加回归测试、修复查询、做一项小型数据库结构变更、运行完整测试套件、部署到测试环境，并说明回滚路径。这个过程能暴露看似合理、却缺乏一致边界或测试切入点的生成代码。

依据证据而非风格偏好判断交接。记录搭建时间、未记录的依赖、失败命令、权责不清、变更路径周围的测试覆盖、审查发现、部署结果，以及需要供应商知识才能回答的问题。要求开发者识别可安全编辑的生成区域，以及在之后的对话变更中可能被平台覆盖的区域。

特别关注重新生成。在导出后做一次常规代码编辑，如果支持，则导入或重新连接项目，然后要求平台在附近生成一项变更。确定平台会保留、重写、重复，还是悄悄与手动编辑冲突。团队需要为人工与生成工作混合制定明确的操作模式。「开发者可以编辑代码」没有说明下一次生成时会发生什么。

若应用缺少可重复测试、数据模型只存在于聊天记录中、生成模块没有稳定边界、手动变更消失，或部署仍需第一位构建者的账户，则交接失败。同一系统生成的文档可以提供帮助，但接收代码的开发者必须根据代码和运行时情况验证它。

干净的交接不要求每位开发者都欣赏生成代码的风格。它要求一名合格开发者能预测变更影响、测试行为、审查安全敏感路径，并在没有私有知识的情况下运行发布流程。

合同应保留已验证的证据

只有在所有阻断性控制项通过，或企业正式接受一项有明确时限且配有补偿性控制的具体例外时，合同才应继续推进。采购部门应将证据定义附在商业承诺中，而不是依赖功能名称。

在评估 Koder.ai 时，应按同样的证据规则检验其源代码导出、部署、托管、自定义域名、快照、回滚、规划模式和按国家部署应用的能力。功能名称只是测试的邀请，不是证据。

围绕七项控制结论建立决策记录。每一项都包括测试版本、环境、证据负责人、观察结果、供应商协助、缺陷引用、复测结果和合同后果。将原始产物保存在企业控制的存储中，让日后的审查人员能区分团队观察到的内容与各方讨论过的内容。

不要将未解决的阻断项变成关于「支持」可移植性、驻留或恢复的模糊合同承诺。定义具体产物或行为：在规定流程内完成源代码导出、列明处理位置、可导出的审计字段、经过测试的恢复路径，或合同终止后持续访问所需构建材料。对影响采用的主张设定补救措施和退出权。

还应保护交接条件。明确生成源代码的所有权和许可用途、导出访问权、数据返还、删除行为、配置获取、审计导出、过渡协助，以及关系终止时已部署应用的处理方式。商业套餐可能不同，但团队在签署前应知道哪些已测试控制取决于所选套餐。

有条件通过必须有负责人和到期日期。在同一环境中复测实际修复结果，并更新原始证据记录。一张介绍计划功能的幻灯片不能关闭一次失败测试，在供应商准备好的项目上演示也不能证明修复适用于你的项目。

当构建的兴奋感消退后，决策仍然清晰，试点就完成了自己的工作。如果团队能在自己的控制下导出、限制、定位、部署、恢复、调查并交接应用，合同就建立在已观察到的能力上。若其中任何一道门槛仍依赖解释，应趁成本还低时记录失败。