企业 AI 项目 Wiki

说明系统从开发、测试到正式运行时需要分清的环境、版本和发布概念。

1. 01版本号版本号是按照一套约定规则分配给某个可变对象状态的标识，用来区分、引用、排序或说明它与其他状态的关系。一个有效的项目版本号必须能回查到明确的对象和变更记录；如果同一个号码可以指向不同内容，或者号码变化却无法说明对应对象，版本号就只能充当展示文字，不能可靠支持部署、验收、回滚和故障定位。查看知识点→
2. 02部署部署是将一个可识别的软件或系统版本，按照受控步骤安装、配置或更新到指定目标环境，并完成依赖、数据库、权限、启动、健康和记录检查，使该环境达到预期运行状态的过程。一次完整部署必须能够说明输入制品、目标环境、执行步骤、变更结果、验证证据和失败后的停止或恢复方式，而不只是“文件已经上传”。查看知识点→
3. 03测试环境测试环境是供测试人员、开发人员或自动化程序运行指定版本并验证预期结果的受控非生产环境。它需要具备明确的测试对象、配置、数据、依赖、访问权限和重置方法，使问题能够被发现、记录、复现和复测，同时避免测试活动影响真实用户和正式数据。查看知识点→
4. 04发布发布是组织授权一个可识别的软件版本、功能或配置，通过指定渠道在规定时间向明确受众变得可获得、可访问或生效，并持续确认其影响的受控过程。发布改变的是使用可用性和暴露范围；它可以通过流量路由、功能开关、账号授权、下载渠道或商店分发完成，也可以与部署发生在不同时间。查看知识点→
5. 05环境隔离环境隔离是让一个生命周期环境中的人员、程序、数据、凭据、变更和故障，不能在未经明确授权与受控路径的情况下访问、改变或影响另一个环境的一组边界和控制。有效隔离不仅把计算资源分开，还要限制身份权限、网络连通、数据流向、密钥使用、部署目标、共享服务和日志访问，并能够通过测试和审计证明这些限制确实生效。查看知识点→
6. 06回滚回滚是发现一次变更造成不可接受结果后，按照预先确认的目标基线和顺序执行新的受控变更，将受影响组件恢复到已知可运行且经过验证的兼容状态，并核对变更期间产生的数据与外部影响。回滚的完成条件不是旧版本重新启动，而是服务、数据、权限、业务流程和观察指标达到事先规定的恢复状态。查看知识点→
7. 07生产环境生产环境是正式承载真实用户、业务数据和业务操作的一整套运行条件。它不只是服务器，也不只是已经部署的代码；它包括访问入口、计算与运行时、网络、数据存储、身份权限、配置与密钥、外部依赖、监控告警、备份恢复，以及负责持续运行这套系统的人和流程。查看知识点→
8. 08用户验收测试环境（UAT 环境）用户验收测试环境（UAT 环境）是供获得授权的业务用户、客户代表或其他验收责任人，使用约定的业务场景和验收标准，对一个可唯一识别的候选版本作正式业务确认的受控非生产环境。它需要提供足以代表目标业务的配置、权限、数据和系统依赖，同时阻断未获授权的正式业务副作用，并保留从测试输入、实际结果、问题处理到签署决定的可追溯记录。查看知识点→
9. 09预发布环境预发布环境是软件进入生产环境之前，用于对生产候选产物、环境配置和正式部署路径进行最后验证的受控非生产环境。它应尽可能复现与本次发布风险有关的生产条件，同时与真实用户、正式数据和不可逆业务操作保持隔离，使团队能在上线前发现由配置、权限、网络、依赖、数据迁移、启动和观测方式造成的问题。查看知识点→
10. 10运行环境运行环境是让指定软件产物能够启动、执行并与所需资源交互的一组实际技术条件。它通常包括处理器与操作系统、语言或应用运行时、系统与应用依赖、启动命令、配置和密钥、身份权限、网络与存储、资源限制，以及运行期间访问的外部服务。代码相同，只要这些条件发生实质变化，程序行为、性能和安全结果都可能不同。查看知识点→

说明项目怎样把需求转成可以执行、留证和确认的测试与验收条件。

1. 01验收版本验收版本是由项目授权方在某一验收轮次开始前正式指定，并与验收范围、环境、标准和证据关联的一套解决方案配置基线。它应列明应用制品、配置、数据库变更、接口与依赖、必要数据状态、文档以及企业 AI 的模型、提示词、知识和工具版本，使所有验收参与者能够确认测的是同一对象；任何实质修改都要形成新基线并重新判断受影响的验收范围。查看知识点→
2. 02验收标准验收标准是项目相关方事先约定、用于判断指定交付物或版本是否可以被接受的一组可验证条件。它要说明验收对象、适用场景、预期结果、允许范围、验证方法、所需证据和确认责任，使“通过”或“不通过”能够依据记录作出，而不是依赖临场感觉。查看知识点→

说明项目做什么、不做什么，怎样形成可报价、可排期、可验收和可变更的共同边界。

1. 01变更请求变更请求是针对一个已识别的文件、交付物或基线提出修改的正式记录。它把现状、拟议状态、提出理由、影响、处理选择、决定权限、实施与验证要求连接起来，使团队在改变承诺或受控系统之前能够先判断是否必要、是否值得、是否安全，并在决定后同步相关基线。查看知识点→
2. 02第一期范围第一期范围是完整项目目标中，经明确授权在第一个约定阶段完成的目标、用户与业务场景、交付结果、必要工作、技术与数据边界、责任、成本和完成条件的集合，并同时标出本期不做、后续再做和依赖外部完成的事项。它应形成自己的可识别基线，使团队能够为这一期单独报价、排期、执行、验收，并在阶段结束时决定继续、调整、重复或停止。查看知识点→
3. 03项目范围项目范围是相关方在一个明确版本中确认的交付边界：为了实现本期目标，要向哪些用户和业务场景交付哪些结果，完成哪些必要工作，接入哪些数据、系统和环境，由谁承担哪些责任，按照什么条件确认完成，以及哪些事项明确不在本期。它是报价、排期、资源、验收和变更判断的共同基准。查看知识点→

说明真实岗位在什么条件下完成什么任务，以及这些场景怎样转成范围、需求、设计和验收依据。

1. 01非功能要求非功能要求是针对系统、产品、服务或其运行环境的质量特征、质量水平或实现与运行约束所作的规范性陈述。它说明功能在什么对象、情境、负载、时间窗口和风险条件下必须达到何种可测结果，或设计运行必须遵守什么有依据的边界，并应可验证、可追溯、可分配和受控变更。查看知识点→
2. 02功能要求功能要求是分配给指定系统层级的规范性陈述，用来规定该系统在明确条件下必须接收、验证、转换、存储、检索、计算、决定、控制、呈现、传输、记录、阻止或恢复什么，并给出能够由系统边界外观察或验证的结果。它应必要、原子、单义、可行、可验证且能双向追溯。查看知识点→
3. 03系统要求系统要求是分配给边界明确的目标系统、在规定条件下必须满足的必要、单义、可行、可验证并可追溯的规范性陈述，用来规定系统行为、性能、接口、信息、质量或约束。全部获批系统要求共同构成设计分配、实现验证、变更控制和交付证据所依据的系统基线。查看知识点→
4. 04相关方要求相关方要求是把某个已识别相关方或相关方类别在明确生命周期与运行情境中的必要服务、交互、质量、信息、控制或约束，转化为共同协调、可追溯、可验证并经有权确认的规范性陈述。它连接上游需要与期望，形成系统要求和解决方案验证的依据。查看知识点→
5. 05性能要求性能要求是对指定系统对象执行指定功能时的速度、延迟、时限、吞吐、并发、处理规模、容量或资源利用水平所作的规范性量化陈述。它必须同时说明工作负载、数据、环境、测量边界、统计口径、阈值和允许失败，使结果能够复现、验证、分配、追溯和受控变更。查看知识点→
6. 06业务场景业务场景是在明确业务上下文中，一个或多个角色为达到可识别结果而执行任务的有边界叙述。它从触发事件和前置条件开始，说明人员、系统与第三方怎样使用信息、作出判断、交接和处理例外，直到进入一个可确认的结束状态，并记录适用范围、频率、规模、风险和限制。查看知识点→
7. 07业务规则业务规则是由组织负责制定、采用或执行，用来界定业务概念、约束可接受状态与行为，或根据已知事实得出业务结论的可管理陈述。它应具有明确权威来源、适用范围、输入事实、结果、例外、优先关系和版本，使人员与系统能够一致判断、执行、解释和复核。查看知识点→
8. 08业务需求业务需求是对组织为了实现已确认业务目的而必须获得的能力、业务结果或高层约束的可管理陈述。它把问题或机会与后续范围、相关方和用户要求、业务规则、解决方案要求、验证及效益衡量连接起来，但保持对具体产品、供应商、界面和算法的适度独立。查看知识点→
9. 09用户角色用户角色是按共同目标、责任、任务和使用上下文，对直接使用服务或参与其业务结果的一类人所作的稳定抽象。它说明这类参与者为什么进入场景、需要知道和完成什么、能够作出哪些业务决定、与谁交接以及受哪些条件限制，而不是用个人姓名或系统账号代替需求。查看知识点→
10. 10用户需求用户需求是用户或一组用户在明确使用情境中，为达到预期结果所必需的、与具体解决方案相对独立的前提。它说明谁在什么情况下需要完成或理解什么、为什么这个结果重要以及当前存在什么阻碍，为后续范围、用户要求、设计、内容、支持和验证提供依据。查看知识点→
11. 11用户要求用户要求是从用户需求、用户能力和使用情境推导出的、对交互系统使用方式和使用结果质量作出的可规定、可验证要求集合。它说明用户为达到目标必须能够怎样与系统交换信息，以及在指定用户、任务与环境中，结果需要达到怎样的有效性、效率、安全性、可访问性或满意程度。查看知识点→