AI 加速产出；工程经验负责判断。
AI 可以加快搜索、分析与方案生成；需求判断、架构取舍、风险接受、验证方式与最终交付仍由工程团队负责。
- 团队累计 30+ 年共数千万元项目经验
- Light Nova 技术团队成员在软件开发、系统集成、代码优化，以及合计数千万元新台币的项目中积累的行业实践经验。
- AI 项目累计数百万新台币以上
- 团队以 AI 辅助开发与优化，并已成功交付之相关项目合计规模。
30+ 年为团队成员的相关经验累计；数千万元新台币为团队参与过之项目的合计规模；AI 项目金额则为相关已交付项目合计。以上均非营收增长、成本节省或未来成效保证。
真正的警讯不是代码难看，而是变更成本开始失去可预测性。
以下情况不一定代表系统必须重写，但表示团队值得先建立行为基准、影响范围与风险排序。
同一项规则出现多个版本
相似逻辑散落在不同页面、服务或任务中；修正其中一份，其他路径仍可能保留旧行为。
小改动牵动不相关功能
状态、数据访问与副作用缺乏清晰边界，使局部需求需要跨越多个模块才能安全完成。
无法重现“当前正确”的行为
缺少测试、示例数据或操作基准时，团队很难判断修复是在保留现有功能，还是意外改变产品。
代码产出增加，审查与发布却变慢
AI 扩大了变更量，但 review、验证与发布能力没有同步增长，待确认的风险便逐次累积。
不追求表面整齐；先恢复对变更的理解与控制。
修复顺序应由产品影响与证据决定，而不是由哪个文件最旧、最乱或最容易重写决定。
- 1
梳理关键行为与依赖
确认用户流程、数据流、外部集成、后台任务与失败路径，建立本次修复边界。
- 2
为高风险流程建立基准
用既有测试、特征测试、日志、操作记录或截图，保存当前必须维持的行为。
- 3
在有实际收益处简化
只在能减少重复决策、变更范围或维护成本时整合结构，不为重构而重构。
- 4
检查信任与部署边界
按范围检查机密、权限、输入、依赖、外部服务及部署／回滚设置。
- 5
让每批修复都有证据
每项变更关联测试、QA 步骤、构建结果、性能数据或双方事先约定的验收信号。
- 6
让下一次变更更容易判断
留下项目指引、重要决策、自动检查与 coding-agent 规则，减少相同问题再次累积。
从依赖记忆与猜测，走向有基准的变更决策。
修复前
- 正确行为只存在于人的记忆
- 同一规则由多条路径各自实现
- 合并后才发现影响范围
- 发布信心依赖临时人工检查
修复后
- 关键行为已有可重现基准
- 重复决策被整合或明确归属
- 变更前已说明影响与回滚方式
- 发布判断有可重复检查支持
这是改善方向，不是所有系统的固定结果。我们会先记录现状、约定验收证据，再判断每一阶段是否完成。
依据问题与约定范围，留下能被接手、验证并继续使用的成果。
代码库检查与风险清单
记录检查范围、关键行为、主要风险、证据来源，以及当前未知或未纳入的部分。
分阶段修复计划
说明每个修复单元的目的、优先级、影响范围、依赖条件、验证与回滚方式。
可审查的修复实现
若包含实现，以小批次变更交付，让差异、决策与风险可以逐次检查。
行为基准与回归证据
依据系统条件提供自动测试、QA 步骤、构建记录、截图或其他约定证据。
团队与 AI 开发护栏
建立适用的项目规则、coding-agent 指引，以及 lint、类型、测试或安全检查。
决策与交接地图
整理主要模块、重要取舍、已知限制、未处理风险与下一阶段建议。
先把问题界定清楚，再决定要修多少。
从下一项重要变更开始
告诉我们产品当前能做什么、接下来要完成什么，以及最不能被破坏的流程。
建立基准并分级风险
确认关键行为、技术限制与现有证据，再按用户、数据、安全与运营影响排序。
按可回滚的小批次修复
每批变更都有明确目的、差异范围、验证方式与必要的回滚说明。
以约定证据验收与交接
共同确认完成条件、记录仍存在的限制，并交付团队可继续使用的下一步。
初步检查可以独立成立，并不代表必须委托全面修复。我们会先提出范围、排除项、验收方式、周期与报价，再由你决定下一步。
接触代码以前，先把答案说清楚。
只处理特定 AI 工具生成的代码吗？
不绑定工具。我们处理 AI 辅助、人工编写、遗留系统及混合代码库，评估重点是当前产品行为、代码结构与交付环境。
会建议全部重写吗？
通常不会。只有现有结构无法合理隔离风险，且全面改写在成本、迁移、验证与回滚方面更可控时，才会将其列为选项；取舍会先说明。
修复期间必须停止产品开发吗？
不一定。我们会评估分支策略、变更边界、功能开关或发布节奏能否让必要开发与修复并行；若不安全，也会说明原因。
如何衡量是否真的改善？
依据问题选择基准，可能包括关键流程结果、可重现失败数、build／type／test 状态、重复决策路径、变更影响范围，以及部署与回滚检查。没有一个分数适合所有系统。
一开始需要 production 或完整 repository 权限吗？
不一定。我们从当前阶段所需的最低权限开始，并另行安排安全渠道。请勿在联系表单发送密码、private key、API key、repository token 或客户数据。
修复后还能继续协助吗？
可以。后续开发、维护、发布支持或定期健康检查可另行约定；也可以只完成检查与交接，不绑定长期合作。
告诉我们：现在能做什么、下一步要做什么、哪里最不能出错。
你可以先提供技术栈、产品阶段、当前可重现的问题，以及下一项重要变更。无需在表单附上源代码或任何机密；密码、private key、API key、repository token 与客户数据请勿发送。
收到需求后，我们会先做三件事
- 1.厘清产品目标、关键流程与本次不处理的范围。
- 2.如需查看代码，另行安排安全且最低权限的方式。
- 3.提供建议选项、验收证据、周期与报价，再由你决定是否进行。