AI Agent 编程助手(CLI)

一、代码实践

Q1: ToolResult 的类型约束

当前 ToolResult 类型定义如下：

export type ToolResult<T = unknown> = {
  success: boolean;
  data?: T;
  error?: string;
};

> 如何实现这样的约束，使得：当 success: true 时，TypeScript 强制要求 data 必须存在；当 success: false 时，强制要求 error 必须存在？

Q2: 单例模式的测试问题

> sessionManger.ts 使用模块级单例：

let sessionManager: SessionManager | null = null;

> 这种单例实现在单元测试中会有什么问题？你会怎么改进以支持测试隔离？

Q3: 长时间运行命令的处理

> runCommandPro.ts 对 npm run dev 这类长时间运行的命令使用非阻塞模式。为什么这样设计？如果用户想要停止这个后台进程，代码中有提供机制吗？你会怎么实现？

二、系统设计与架构

Q4: 容错降级设计

> 我看到 checkpointer.ts 中，当 SQLite 初始化失败时会降级为内存模式（MemorySaver），这种容错设计有什么优缺点？在什么场景下你会选择直接报错而不是降级？

Q5: LangGraph 中断机制原理

> 代码中使用了 interrupt() 来暂停 Agent 执行等待用户确认敏感操作。你能用最简单的语言解释 interrupt 机制的底层工作原理吗？它是如何实现"暂停执行→等待外部输入→恢复执行"这个流程的？

Q6: 状态图 vs 链式调用

> 当前 Agent 使用 StateGraph 编排 summarizerNode → llmCall → toolNode，为什么不直接用简单的链式调用（Sequential Chain）？状态图在这个场景下解决了什么问题？

Q: 可观测性设计

> 你了解软件工程的可观测性吗？比如你怎么知道用户的程序运行出问题了，你会通过什么方式监控程序报错，持续提升软件的可靠性。

Q: AI Agent 框架

> 当前这个项目使用了 LangGraph 作为 Agent 基础框架，你觉得它的优缺点是什么？你了解过其他 Agent 框架吗？

三、安全机制

Q7: 安全措施的全面性

> 对于这个 Coding Agent，代码中做了哪些具体的安全措施？（提示：可以从命令执行、文件操作、路径检查等角度回答）这些措施有什么局限性？你能想到更好的方案吗？

Q8: 白名单策略的漏洞

> runCommandPro.ts 中使用命令白名单 ['node', 'npm', 'pnpm', ...]，但白名单中的 node 可以执行任意代码，比如 node -e "xxx"。当前的安全机制能防住吗？你会怎么改进？

Q9: 路径遍历攻击

> security.ts 使用 relative(root, resolvedPath) 检查路径是否越界。如果攻击者构造路径 /project/../../../etc/passwd，这个检查能防住吗？符号链接（symlink）攻击呢？

四、上下文工程

Q10: 上下文压缩策略改进

> 当前的 CompressionStrategy 是基于消息轮次（rounds）数量触发压缩的。这种方式有什么问题？有没有更好的压缩触发策略？你会怎么实现？

Q11: Token 估算的准确性

> 代码中用 text.length / 4 来估算 token 数量。这个估算对于中文内容准确吗？如果要支持多语言，你会怎么改进这个估算逻辑？

Q12: UI 消息与模型消息分离

> CompressionStrategy 同时维护了 processedMessages（给 UI 显示）和 modelMessages（给模型使用）。为什么要分离这两套消息？这种设计解决了什么问题？

Q13: System Prompt 的约束有效性

> systemPromptTemplate.ts 中有大量行为约束（如"禁止顺便写测试"、"禁止主动执行命令"）。这些约束在实际使用中可靠吗？如果模型"不听话"，你有什么技术手段可以强制执行这些约束？

Q14: 任务边界的判断

> Prompt 中要求"任务范围只等于当前这条用户消息"，但如果用户说"帮我把这个项目重构一下"，这个任务边界应该怎么界定？你会怎么设计让 Agent 主动澄清任务范围的机制？

五、错误处理与重试

Q15: 重试策略的边界

> node.ts 中工具执行失败时会进行指数退避重试，但只对非 ErrorTypes.TOOL 类型的错误重试。为什么 TOOL 类型的错误不应该重试？你能举例说明什么情况下重试是有害的？

Q16: 错误分类的设计意图

> errors.ts 定义了多种错误类型（AUTH、RATE_LIMIT、NETWORK、SAFETY、TOOL、RUNTIME 等）。这种细粒度的错误分类对 Agent 的行为有什么影响？模型应该如何根据不同错误类型采取不同策略？

六、产品设计与用户体验

Q17: 撤销功能设计

> 假设 Agent 执行了 write_file 或 replace_in_file 修改了用户的代码，但用户不满意想撤销。你会如何设计这个撤销功能？需要考虑哪些边界情况？（提示：参考 Cursor、Copilot 等工具的做法）

Q18: 敏感操作确认的用户体验

> 代码中对 write_file、run_command、delete_file 等操作都设置了 requireConfirm: true。但如果用户觉得每次确认很烦，想要"全部允许"或"记住我的选择"，你会怎么设计这个功能？有什么安全风险需要考虑？

七、团队建设

> 你作为项目组长，我理解是一号位角色，你通过持续沟通与正向激励提升团队协作氛围，可以说说具体做法吗，比如哪些形式的正向激励。如果团队成员不配合产生消极情绪，你会如何行动？临时补位或是有其他办法？

文档中心

一、状态管理与架构设计

Q1: Pinia 状态设计

> 文档中心涉及多种安全等级的文档分类管理。你是如何用 Pinia 组织这些状态的？如果有一个文档同时被"金库审批"和"审计模块"两个页面使用，状态应该放在哪里？如何避免状态冗余和同步问题？

Q2: 计算与展示解耦

> 你提到"重构展示链路，实现计算与展示解耦"。能具体说说之前是什么样的耦合问题？你是如何设计这个解耦方案的？这种解耦对单元测试有什么帮助？

Q3: 模块化边界

> 审批模块、审计模块、金库模块之间有哪些数据或逻辑是共享的？你是如何划分模块边界的？如果产品要求"审批通过后自动触发审计记录"，这个逻辑应该放在哪个模块？

二、表格与导出

Q4: vxe-table 选型理由

> 为什么选择 vxe-table 而不是 Element-Plus 自带的 el-table？在什么场景下 vxe-table 的优势会体现出来？

Q5: 大数据量导出

> 如果用户要导出 10 万条审计记录，前端直接用 xlsx 库处理会有什么问题？你是如何设计"导出过程状态反馈与交互兜底"的？如果导出到一半浏览器崩溃了，用户体验应该如何保障？

Q6: 导出失败率优化

> 你提到"导出失败率显著下降"，能说说之前失败的主要原因是什么？你做了哪些具体的优化措施？如何监控和量化"导出失败率"这个指标？

三、用户体验与交互

Q7: 审批弹窗规范化

> "审批详情弹窗规范化"具体规范了哪些内容？如果不同审批类型的弹窗内容差异很大，你是用一个通用弹窗组件还是多个专用组件？如何平衡复用性和灵活性？

Q8: 空态设计

> "空态规范化"是指什么？列表为空、搜索无结果、权限不足这三种空态应该如何区分展示？你是如何让团队统一遵守这个规范的？

Q9: 减少误触

> 你提到"减少无效操作与误触"，能举个具体的例子吗？对于"删除文档"这种高风险操作，你会设计怎样的防误触机制？除了二次确认弹窗还有其他方案吗？

Q: 用户体验其他维度

> 对于用户体验，除了空态展示、状态反馈、交互兜底外，你还遇到过哪些维度？

四、数据安全与边界处理

Q10: 文档安全等级

> 这个项目"以数据安全为核心"，那么前端在文档安全管控中承担什么职责？前后端安全校验的边界在哪？应该如何配合？

Q11: 边界数据处理

> 你提到"补齐边界数据处理与验证"，能举几个具体的边界 case 吗？比如文档名称为空、文件大小为 0、创建时间是未来时间，这些情况前端应该如何处理？是直接过滤还是展示异常标记？

Q12: 列表展示异常

> "列表展示异常"的根因是什么？是前端渲染问题还是后端数据问题？你是如何定位这个 bug 的？修复后如何保证不再复现？

五、工程化与协作

Q13: TypeScript 实践

> 在这个项目中，TypeScript 主要解决了什么问题？你是如何定义文档、审批单、审计记录这些业务类型的？有没有遇到类型定义和后端接口不一致的情况？如何处理？

Q14: 组件设计原则

> 如果让你设计一个"文档卡片"组件，既要在列表页用、也要在详情弹窗用、还要在审批流程中用，你会如何设计这个组件的 props 和 slots？如何避免这个组件变成一个"万能组件"？

Q15: 迭代成本控制

> 你提到"降低后续需求迭代成本"，能具体说说你做了什么来实现这个目标？

六、性能与稳定性

Q16: 长列表性能

> 假设文档列表如果有几千条数据，你会如何优化渲染性能？虚拟滚动在这个场景下适用吗？如果用户要"全选导出"，虚拟滚动会带来什么问题？

Q17: 发布稳定性

> 你提到"保障发布稳定性"，发布稳定性怎么衡量？在发布前你会做哪些检查？如果线上出现了严重 bug，你会采用什么措施？你是否了解回滚方案、灰度发布机制？

Q18: 错误监控

> 这个项目已上线运行，有 2000+ 用户，你们有前端错误监控吗？如果用户反馈"页面白屏"，但你在本地复现不了，你会如何排查？