复杂动态长上下文管理
复杂的开放性问题：无限长、动态变化的需求上下文。 大模型也无法一步到位解决需求。
需求管理
需求本身就很复杂，需求管理本身就有不小的工作量。
你有尝试过作为甲方用户，在一个项目中向大模型提过一长串需求吗？
常见问题
- 需求已经实现了，但人类不知道，继续要求实现冗余需求。
- 凭空创造不该出现的功能特性，被客户认为开后门。
- 依赖的服务报错，
决策难点
架构与设计模式决策
水平差的人类经常做出错误的架构设计。 水平差的人类，如果向大模型发出了错误的决策，大模型出于对人类偏好的对齐，自然也会坚决执行错误的决策，越走越偏。
问题修复方案决策
一个Bug可能有多种修复方式：
- 可以在不同层级的模块上修复
- 侵入式代码适配 vs. 从根本上改变内部设计or外部接口约定
- 可以在本模块内做侵入式适配（if 当前table是增量物化视图内部产生的临时表，跳过Vacuum），改动代码少，但导致了侵入式修改。
- 可以要求增量物化视图模块从根本上避免分布式下的Vacuum失败（强行让多个CN之间的临时表名称完全相同，但这可能动的是整个增量物化视图代码的基础逻辑？）
需要人类决策，和人类意图对齐，保证代码可维护性。
可信软件工程
上下文缺失
测试集越全面完整、对bug容忍度越高、上下文越完整，越可以放心大胆让Agent跑长程任务。
但在系统软件开发领域，常常面临以下困境：
- 测试集不全面：
- 针对一个模块的CI测试包含门禁CI、日构建流水线测试（完整运行3小时起步）、周构建流水线测试。
- 其它模块的单元测试数量也非常多。
- 更多复杂的黑盒测试用例在测试工程师手上（可能包含无法自动化的测试）。
- 测试集本身看护不全：并发场景、特殊时序关系下才能触发的bug，似乎难以自动化用例。（或许可以采用插桩的方式控制时序）
- 和历史特性、其它特性交叉的测试集。
- 各类专项测试，如FUZZ、安全渗透、性能测试……
- 系统集成测试、长稳测试的回归至少需要跑3天以上（约1~5小时偶现一次的bug）。
- 人和大模型对其它模块的认知不够完整。
- 其它模块中看似是bug的地方，可能有着不为人知的约束条件，或者修改影响面过大，或者涉及行为变更。
用户信任
金融领域对数据库系统的Bu的容忍程度低，尤其是数据不一致问题。 产品功能的上线、客户信任的建立往往以年甚至10年为单位。
软件工程过程审计
10个1000行的commit，显然比 一个10000行的commit更容易被人和大模型接受。因为10个commit相对1个commit，提供了中间的思维链过程，包含了更多信息量。
Agent自动生成的测试套件不全面、偏离真实需求
不会主动加一些新的测试，比如代码覆盖率测试。
禁止引入未被记录的行为
面对大型项目，Vibe用户的需求管理可能十分混乱。
架构不可维护
- 倾向于在原有逻辑的基础上添加，导致文件越来越长，不会主动重构代码。
- 关注局部代码与测试，破坏整体架构。混用旧版和新版架构逻辑。
可观测性
当下Agent仍然需要指导它去生成一些辅助可观测性的代码。
自然语言编程
语言不重要，算法思想更重要
懂得专业名词才能与Agent更加高效地交流
检查每一行Agent生成的代码 vs. 一行Agent生成的代码都不看
- Robert C. Martin: 一行agent生成的代码都不看。
- Mitchell Hashimoto：检查每一行agent生成的代码1。
- Andrej Karpathy：AI Agent检查代码，每一行改动都能追溯到原始需求。
- Linus Torvalds：人要对代码生成的结果负责。