客户侧
不知道如何完整描述一项变化；看不懂一个小要求为何变成大成本；看不到供应商如何理解与实施；确认依赖邮件和会议纪要；验收时无法还原「原需求—变更—交付」的关系。
软件项目里的变化散落在会议、邮件、聊天、文档和工单中。Keel 把它们变成可解释、可评审、可追踪、可审计的正式变更资产，减少范围争议、影响遗漏、返工和验收扯皮。
Keel 的产品价值，就是持续、证据化地回答这些问题。
以跨组织需求共识为对象，以 AI 影响分析为核心，以既有研发平台为执行端。
传统 ALM/RM 擅长基线与正式评审，但实施复杂、客户协作弱；研发管理平台擅长任务流转，却容易把需求变更降格成一个普通事项。Keel 占据中间空白：它是变更的 System of Record 与跨系统 System of Control，而不是团队日常干活的 System of Work。
不知道如何完整描述一项变化；看不懂一个小要求为何变成大成本；看不到供应商如何理解与实施；确认依赖邮件和会议纪要；验收时无法还原「原需求—变更—交付」的关系。
变更散落在微信、会议、邮件和工单里；售前承诺、合同范围与研发理解互相偏离；影响分析靠少数专家，容易遗漏；「细化还是新增」没有统一证据；批准后下游对象无法保证同步。
无法统计变更来源、决策时长和返工成本；难以追责，也无法证明已经完成必要分析；缺少可复用的变更模式；利润被频繁的小变更静默侵蚀。
不以项目、任务或文档为中心。一次需求变化从发现到关闭，都装在同一个控制容器里。
客户原始表达、附件和发生时间永久保留。AI 整理结果不得替代原始事实。
所有 AI 影响判断必须给出证据、关系路径、置信度和建议动作。禁止没有证据的「可能受影响」标签。
AI 可以发现、追问、分析、推荐和监督，但不得代替责任人正式批准、客户签署或强制关闭。
客户看到业务影响和待确认事项；内部人员可查看工程、商务及风险细节。字段级可见性：内部 / 共享 / 客户。
任务、缺陷、代码、测试执行仍在既有系统中完成。Keel 只控制变更闭环，支持独立部署。
首页不展示泛化项目 KPI，而围绕「需要处理的变化」：高风险信号、待澄清问题、超时影响评审、待决策 Brief、传播失败与客户异议。
从门户、邮件、会议纪要、文档和工单持续发现变化。AI 区分变更、缺陷、咨询、补充和重复请求，但禁止静默创建正式变更。每张卡片同时给出原文、判断、关联需求和一键动作：新建、合并、忽略、转人工。
一个页面承载完整事实、分析、协作和状态。原始诉求冻结不可覆盖。结构化 Change Statement 用 Before / After / Rationale / Acceptance 描述「意义上改变了什么」，而不是字符级文档比较。右侧是按上下文工作的 AI 洞察，不是通用聊天窗。
沿显式追踪图多跳遍历，再用语义召回找出图上没有、但真实受影响的对象。每个候选必须带对象、路径、证据、置信度和人工处置：纳入、不受影响、需调查。高风险领域优先保证召回。
把影响结果变成可比较的方案（保守、平衡、最小改动），输出 T-shirt 工作量而不是伪造精确人日。一页式变更简报供 CCB 批准、附条件批准、拒绝或延期。正式决策必须由人作出。
批准后生成传播清单，把草案推到 Jira / ONES / Webhook，并回收状态。关闭前执行门禁：决策条件、影响处置、关键同步、必需验证、客户确认、新基线与审计记录。未满足则普通用户无法关闭。
给客户隔离的协作入口：提交变化、回答澄清、确认范围与验收。客户不看到内部备注、成本底稿和技术术语。生成客户摘要前先做可见性过滤，并可「以客户身份预览」。
影响分析建立在结构化基线之上，而不是让模型直接阅读全部文档后猜测。需求快照、正式基线、显式 Trace Link 与 AI 建议链接；变更后标记存疑；显示覆盖率与孤立对象。
补充状态包括已合并、已拆分、已撤回、重新打开。状态转换写入追加式审计链。
Change Radar、结构化定义、澄清规划、语义差异、影响引擎、方案模拟、决策简报、传播规划与闭环审计，各自有输入、输出和人工控制点。模型不可用时，基线、审批和人工分析仍可运行。
结论、可定位证据、可审查的判断依据、置信度、不确定性、建议动作、对客户是否可见、模型与输入版本记录。推断不得写成已确认事实。
| 角色 | 目标 | 典型动作 |
|---|---|---|
| 客户提出人 / 确认人 | 说清变化并确认业务含义 | 提交、澄清、异议、签署 |
| 需求分析 / 架构 / 测试 | 把变化变成可分析的定义与影响 | 分诊、语义差异、影响确认 |
| 交付 / 商务 / CCB | 组织决策并判断范围与费用 | 简报、批准、附条件、超范围标记 |
| 审计 | 证明过程完整 | 只读全局、导出证据包 |
外部对象只保存必要快照与链接。P0 连接 Jira、ONES 与通用 Webhook。MCP 向企业 Agent 开放查询、提交信号、补充证据和传播草案，但不直接开放批准、签署或强制关闭。
完成证据化闭环的有效变更数：在约定时限内完成澄清、影响确认、决策、传播、验证和客户确认，且证据完整的 Change Case 数量。
查看真实界面与操作步骤，从使用手册开始。