复杂动态长上下文管理
复杂的开放性问题：无限长、动态变化的需求上下文。 大模型也无法一步到位解决需求。
需求管理
需求本身就很复杂，需求管理本身就有不小的工作量。
你有尝试过作为甲方用户，在一个项目中向大模型提过一长串需求吗？
决策难点
一个Bug可能有A、B、C、D四种修复方式，需要人类决策，和人类意图对齐。
可信软件工程
上下文缺失
测试集越全面完整、对bug容忍度越高、上下文越完整，越可以放心大胆让Agent跑长程任务。
但在系统软件开发领域，常常面临以下困境：
- 测试集不全面：
- 针对一个模块的CI测试包含门禁CI、日构建流水线测试（完整运行3小时起步）、周构建流水线测试。
- 其它模块的单元测试数量也非常多。
- 更多复杂的黑盒测试用例在测试工程师手上（可能包含无法自动化的测试）。
- 测试集本身看护不全：并发场景、特殊时序关系下才能触发的bug，似乎难以自动化用例。（或许可以采用插桩的方式控制时序）
- 和历史特性、其它特性交叉的测试集。
- 各类专项测试，如FUZZ、安全渗透、性能测试……
- 系统集成测试、长稳测试的回归至少需要跑3天以上（约1~5小时偶现一次的bug）。
- 人和大模型对其它模块的认知不够完整。
- 其它模块中看似是bug的地方，可能有着不为人知的约束条件，或者修改影响面过大，或者涉及行为变更。
用户信任
金融领域对数据库系统的Bu的容忍程度低，尤其是数据不一致问题。 产品功能的上线、客户信任的建立往往以年甚至10年为单位。
软件工程过程审计
10个1000行的commit，显然比 一个10000行的commit更容易被人和大模型接受。因为10个commit相对1个commit，提供了中间的思维链过程，包含了更多信息量。