Code Agent 用户调研
Survey Description
感谢您参与本次调研！
本问卷旨在了解开发者使用 Code Agent 的真实体验，打磨更好用的 AI 编码工具。
问卷共 61 题，主要为选择和填空题，预计填写 20~30 分钟。
主要分为个人职业画像、各开发阶段使用体验、效率感受、个性化评测案例征集四个板块。
您的每一份反馈都十分宝贵，感谢耐心填写！
Start answering
00:00:00
Code Agent 用户调研
录音中...
*
📋 进度：第一板块 了解您的职业背景、技术栈和工具使用情况。
1. 您所在团队的核心业务领域?
A. 泛互联网（社交、内容、电商、本地生活、出行等）
B. 新零售/连锁零售
C. SaaS/企业服务
D. 金融（银行、保险、证券、资管、支付）
E. 金融科技/互联网金融
F. 政企/国央企/信创
G. 高端制造（汽车、半导体、机械、工业软件）
H. 能源/化工/电力
I. 生物医药/医疗健康
J. 游戏/娱乐/文创
K. 教育/培训
L. 安全/数据/隐私
M. 通信/运营商
N. 大模型/AI 公司/云基础设施厂商
O. 出海/跨境
P. 咨询/系统集成/外包
Q. 学术/科研院所
R. 其他
*
*
2. 您当前的主要职业角色?
A. 后端开发工程师
B. 前端/全栈开发工程师
C. 测试/QA 工程师
D. 架构师/技术负责人
E. DevOps/SRE/运维工程师
F. 安全工程师
G. 嵌入式/硬件开发工程师
H. 数据工程师/数据科学家
I. 算法/AI 工程师
J. 技术管理者
K. 产品经理（有编码经验）
L. 非技术背景（通过 AI 编程）
M. 其他
*
*
3. 您的软件开发经验年限?
A. 不足 1 年
B. 1 至 3 年
C. 3 至 5 年
D. 5 至 8 年
E. 8 至 15 年
F. 15 年以上
*
4. 您目前主要负责的业务系统或模块是什么?示例:"负责证券交易撮合引擎的订单路由模块"、"负责跨境电商风控算法"
*
5. 您工作中的代码主要运行在哪类技术栈?示例:"Spring Cloud + MyBatis + Kafka，800+ 微服务"、"Next.js + tRPC + Prisma，单仓库前后端"
*
6. 您日常打交道的代码库类型?
[Multiple]
A. 新项目，从零搭建（不满半年）
B. 活跃迭代中的产品代码
C. 5 年以上的遗留系统
D. 内部工具/脚本/数据管线
E. 客户定制化项目（多分支并行）
F. 开源项目或 SDK
G. 其他
*
*
7. 您当前最常用的 Code Agent 工具?
[Multiple]
A. Cursor
B. Claude Code
C. GitHub Copilot
D. Windsurf（Codeium）
E. Trae（字节跳动）
F. OpenAI Codex
G. Cline
H. Augment Code
I. Qoder（通义灵码）
J. Devin
K. 其他
*
*
8. 您所在业务是否存在以下特殊约束，使得 Code Agent 的使用受限?
[Multiple]
A. 数据合规:敏感数据不能进外部模型
B. 信创要求:必须使用国产模型或本地部署
C. 知识产权:核心代码禁止上传
D. 离线/内网环境:无法访问云端模型
E. 安全审计:AI 代码进入代码库前必须通过严格门禁
F. 没有特别约束
G. 其他
*
📋 进度：第二板块是问卷的核心部分，按七个开发阶段分组。每个阶段的首题是"是否使用过"，若选择"从未使用"，该阶段后续题目可直接跳过。预计每阶段填写不超过3min。剩余20min。
需求理解与方案设计 阶段一 / 共七个阶段
*
9. 您是否用过 Code Agent 辅助"需求理解与方案设计"相关工作?
A. 经常使用（每周多次）
B. 偶尔使用（每月几次）
C. 试过但放弃了
D. 从未使用
*
10. 在需求理解与方案设计阶段，您用 Code Agent 做过以下哪些任务?
[Multiple]
A. 拆解和筛选需求（区分核心需求与伪需求，识别隐含前提和冗余条目）
B. 生成技术方案或架构方案（含技术栈选型、中间件配置、部署架构）
C. 理解和澄清模糊需求（让 Agent 主动追问歧义点）
D. 理解行业专有术语或业务规则（如金融风控术语、工业 DFM 参数、游戏内部称呼）
E. 生成技术文档或方案文档初稿
F. 阅读大量已有代码并生成流程图或模块依赖图
G. 评估和比较多个技术方案（独立给出优劣判断）
H. 任务拆解（将复杂任务分解为子任务，含依赖关系和执行顺序）
I. 识别跨模块关联风险（主动提示当前修改对上下游模块的影响）
J. 其他
*
*
11. 上述任务中，Agent 整体完成效果如何?
A. 基本满意，产出可直接使用或只需微调
B. 需要中等修改，Agent 产出作为初稿尚可
C. 需要大量修改，产出仅供参考
D. 完全不可用，不如自己从头写
*
12. 在需求设计阶段使用 Code Agent 时，您遇到过以下哪些问题?
[Multiple]
A. Agent 套用通用模板，不结合我的项目具体约束（如给 Kafka 调优方案时用通用参数，未考虑实际消息处理耗时）
B. Agent 对我所在行业的专有术语理解不足，例如金融穿透式监管概念、游戏内部称呼、工业控制参数等
C. 需要反复修正，Agent 不能一次理解我的意图，例如不确认字段语义就按常见用法猜测
D. Agent 在方案比较时倾向于迎合用户，缺乏独立判断（用户倾向哪个方案，Agent 就附和哪个，无法给出客观对比）
E. Agent 追问功能在需求本身不明确时效果有限（Agent 追问出来的问题大多流于表面，难以触及真正核心需求）
F. Agent 无法主动识别跨模块的关联风险（只关注当前模块，不提示对上下游的影响）
G. Agent 对创新方向和策略决策无法给出有价值建议（技术方向和产品策略仍需人工判断，Agent 只能执行不能决策）
H. 未遇到明显问题
I. 其他
*
*
13. 以上问题中，对您影响最大的是哪一项?
*
14. 遇到上述问题时，您通常如何处理?
[Multiple]
A. 人工补全 Agent 遗漏的部分，Agent 输出作为初稿
B. 将任务拆得更细后重新交给 Agent
C. 先写详细的 prompt/规则文档再让 Agent 执行
D. 换一个模型或工具重试
E. 放弃 Agent，全程人工完成
F. 其他
*
*
15. 放弃的主要原因是?
编码实现 阶段二 / 共七个阶段 预计填写3min.
*
16. 在编码实现阶段，Code Agent 在您日常编码中的参与程度?
A. 几乎全部代码由 Agent 编写，我只做审查（AI 编码渗透率约 90% 以上）
B. Agent 生成主体框架，我修改细节和业务逻辑（渗透率约 50% 至 90%）
C. Agent 辅助部分函数或片段，我写大部分代码（渗透率约 20% 至 50%）
D. 仅用 Agent 做补全（Tab 续写，渗透率不到 20%）
*
17. Agent 生成的代码，您通常需要做多少人工修改才能合入代码库?
A. 几乎不需要修改，直接可用
B. 小幅调整（修改不超过 10% 的生成内容）
C. 中等修改（修改 10% 至 30%，如补充业务规则和防御性逻辑）
D. 大量修改（修改超过 30%，Agent 输出只能作为参考）
E. 基本需要重写
*
18. 在编码实现阶段，您遇到过以下哪些问题?
[Multiple]
A. 跨文件联动修改遗漏，改了一个文件但漏改了需要同步修改的关联文件
B. Agent 声称已全部完成，但实际存在遗漏或误改了不相关的代码
C. 生成的代码能编译通过但缺少关键业务规则，例如该串行执行的校验逻辑被实现为并行、流程步骤不完整
D. 防御性逻辑缺失，例如并发场景下缺少锁或状态保护，容易引发数据一致性问题
E. 过度修改，只要求修复一个 bug 但 Agent 擅自重构周边代码或添加未要求的功能
F. 不复用项目已有组件，倾向于重新造轮子，把简单的事情过度复杂化
G. 不遵循项目编码规范，例如不走统一配置中心、不遵守分层架构约定
H. 杜撰不存在的 API、配置项或文档内容，生成的代码调用了实际不存在的接口或引用了编造的标准条文
I. 嵌入式或硬件平台约束理解不足，例如搞错硬件通道数、寄存器地址、字节序等底层参数
J. 跨语言项目中状态不一致，例如一端改了新状态另一端仍用旧的硬编码值
K. 异步或并发代码质量差，例如把并发逻辑改成同步阻塞、线程池配置有误
L. 多步任务执行时遗漏子任务，任务量大时需要反复纠正才能全部完成
M. 不同对话或不同时间段生成的代码风格不一致
N. 未遇到明显问题
O. 其他
*
*
19. 以上问题中，对您工作影响最大的是哪一项?
*
20. 您是否采取过以下措施来提升 Agent 的编码质量?
[Multiple]
A. 在项目根目录放置规则文件（如 .cursorrules、CLAUDE.md、.github/copilot-instructions.md）
B. 在 prompt 中明确约束修改范围，要求只改指定文件或指定行，不做其他改动
C. 先让 Agent 生成方案/计划，确认后再生成代码（plan 模式）
D. 先人工定义模块边界、函数名和职责，Agent 只负责填充实现
E. 用另一个模型或 Agent 交叉审查第一个 Agent 的代码
F. 将任务拆到单文件粒度，避免跨文件联动
G. 没有采取特别措施
H. 其他
*
*
测试 阶段三 / 共七个阶段
21. 您是否用过 Code Agent 辅助测试工作?
A. 经常使用（每周多次）
B. 偶尔使用（每月几次）
C. 试过但放弃了
D. 从未使用
*
22. 在测试阶段，您用 Code Agent 做过以下哪些任务?
[Multiple]
A. 生成单元测试用例（含正常、边界和异常场景）
B. 采用 TDD 流程（先让 Agent 写测试再实现功能）
C. 生成测试数据或 mock 数据（含前置状态数据准备）
D. 整理复杂业务的测试点清单（如支付状态机流转的全部分支）
E. 回测/回归测试自动化（边界清晰、无副作用、可反复运行的场景）
F. 其他
*
*
23. 上述任务中，Agent 整体完成效果如何?
A. 基本满意，产出可直接使用或只需微调
B. 需要中等修改，Agent 产出作为初稿尚可
C. 需要大量修改，产出仅供参考
D. 完全不可用，不如自己从头写
*
24. 在测试阶段使用 Code Agent 时，您遇到过以下哪些问题?
[Multiple]
A. Agent 生成的测试用例覆盖率不够，正常流程尚可但边界条件和异常分支系统性缺失
B. 复杂业务的测试点遗漏，例如只覆盖正向流程而遗漏异常回退、补偿、幂等等关键分支
C. Agent 自己写代码又自己写测试，测试和代码存在相同的认知盲区，无法发现系统性缺陷
D. 测试中的接口路径或字段部分是编造的，也没有处理测试所需的前置状态数据准备
E. 端到端测试仍然必须人工介入，涉及硬件交互、跨系统联调等场景时 Agent 无法独立完成
F. 视觉表现层的测试 Agent 无法判断，例如像素级差异、交互体验、UI 还原度等需要人眼确认
G. 编码效率提升后，测试验证反而成了最耗时的环节，成为新的瓶颈
H. 涉及资金或合规的测试需要财务审计或第三方介入，Agent 无法替代
I. 未遇到明显问题
J. 其他
*
*
25. Agent 生成的测试用例，您通常还需要补充多少测试场景?
A. 不需要补充，Agent 覆盖已足够
B. 补充少量边界场景（不到 20%）
C. 需要补充较多异常和边界场景（20% 至 50%）
D. 需要补充大量场景（超过 50%），Agent 只覆盖了正常路径
E. Agent 生成的用例基本不可用，需要重写
*
辅助调试与排错 阶段四 / 共七个阶段
26. 您是否用过 Code Agent 辅助调试与排错?
A. 经常使用（每周多次）
B. 偶尔使用（每月几次）
C. 试过但放弃了
D. 从未使用
*
27. 在调试排错阶段，您用 Code Agent 做过以下哪些任务?
[Multiple]
A. 分析报错日志定位问题（将日志发给 Agent，让它编写脚本分析和定位瓶颈）
B. 修复已知 bug（给定 bug 描述和报错信息，让 Agent 定位并修复）
C. 定位性能瓶颈（分析慢查询、CPU/内存热点等）
D. 分析安全告警（含跨设备关联和加密流量解析）
E. 数据分析与归因（基于多张表做根因归因）
F. 其他
*
*
28. 上述任务中，Agent 整体完成效果如何?
A. 基本满意，产出可直接使用或只需微调
B. 需要中等修改，Agent 产出作为初稿尚可
C. 需要大量修改，产出仅供参考
D. 完全不可用，不如自己从头写
*
29. 在调试排错阶段使用 Code Agent 时，您遇到过以下哪些问题?
[Multiple]
A. Agent 给出通用排查清单而非精准定位根因，建议过于泛泛而没有针对具体场景分析
B. Bug 修复的假阳性，看似修好了实际没解决根本问题，例如只是在报错处加了异常捕获掩盖了真正错误
C. 修改一个功能时破坏了原有逻辑，引入回归 bug
D. Agent 无法触达真实运行环境导致排查受限，需要人工反复提供日志等环境信息，效率被来回传递拖累
E. 信息不全时 Agent 仍然给出高置信度答案，不主动表达不确定性，容易误导决策
F. 纯推理场景下数学计算不可靠，不借助代码执行时容易出现基本计算错误
G. 数据分析归因错误，少提供一张关联数据表就可能把结论归因到完全不同的方向
H. 安全告警分析中，明文流量解析可用但加密流量的解析结果与实际内容完全不一致
I. 跨端因果链未追踪，Agent 倾向于在当前端排查，而真实原因可能在另一端的接口或配置中
J. 未遇到明显问题
K. 其他
*
*
30. Agent 辅助排查时，从您开始使用到最终定位根因，平均需要多少轮对话?
A. 通常 1 至 2 轮即可定位
B. 通常 3 至 5 轮
C. 通常 6 至 10 轮
D. 超过 10 轮，但仍比人工快
E. Agent 基本无法帮助定位，最终靠人工经验
*
代码审查与安全 阶段五 / 共七个阶段
31. 您是否用过 Code Agent 辅助代码审查或安全检查?
A. 经常使用（每周多次）
B. 偶尔使用（每月几次）
C. 试过但放弃了
D. 从未使用
*
32. 在代码审查与安全阶段，您用 Code Agent 做过以下哪些任务?
[Multiple]
A. PR/MR 代码 review，用单个 Agent 审查代码变更
B. 多 Agent 交叉审查，用不同模型或不同 Agent 分别 review 同一段代码后合并结论
C. 变更影响面分析，评估改动影响哪些模块，包括动态代理、定时任务等不易发现的隐式依赖
D. 法规合规文档的结构化拆解，将法规原文转为可逐项检查的合规清单
E. 安全漏洞扫描或合规检查
F. 用另一个 Agent 检查第一个 Agent 生成的代码，实现写和查的双道质量控制
G. 其他
*
*
33. 在代码审查与安全阶段使用 Code Agent 时，您遇到过以下哪些问题?
[Multiple]
A. Agent 只能识别通用风险，无法识别业务特定的高风险操作
B. 变更影响面分析遗漏隐式依赖，未发现间接调用、定时任务、历史脚本、配置表引用等隐蔽调用路径
C. 信息不足时 Agent 不降低置信度、不主动要求澄清，给出高置信但错误的审查结论
D. AI review 反而增加了合并前的审阅成本，误报多、建议不够精准
E. Agent 做安全审计时遗漏合规要求，例如未发现审计日志泄露敏感数据、日志记录不完整等问题
F. 未遇到明显问题
G. 其他
*
*
34. 您是否对以下代码类别有意不让 Agent 介入?
[Multiple]
A. 安全/隐私相关代码（加密、认证、授权、脱敏）
B. 涉及资金的核心业务逻辑（支付、清算、对账）
C. 涉及合规审计的代码（审计日志、监管报表）
D. 涉及敏感数据处理的代码（PII、医疗数据、征信数据）
E. 没有特别禁止
F. 其他
*
*
部署与运维 阶段六 / 共七个阶段
35. 您是否用过 Code Agent 辅助部署与运维工作?
A. 经常使用（每周多次）
B. 偶尔使用（每月几次）
C. 试过但放弃了
D. 从未使用
*
36. 在部署与运维阶段，您用 Code Agent 做过以下哪些任务?
[Multiple]
A. 打包与测试环境部署
B. 编写 CI/CD 流水线配置，减少人工在持续集成流水线上的操作
C. 运维流程自动化，将运维操作手册转化为 Agent 可执行的工作流
D. 编写部署脚本或基础设施即代码，例如 Dockerfile、K8s 配置、Terraform 等
E. 安全运营闭环，从告警到研判到处置全程由 Agent 协助完成
F. 其他
*
*
37. 以下哪些顾虑导致您不愿让 Agent 参与部署或运维?
[Multiple]
A. 正式环境上线不交给 AI，技术上虽可行但出于安全考虑仍倾向人工操作
B. 关键基础设施的服务器操作不交给 AI，例如代码仓库、CI 系统、镜像仓库等核心服务
C. 希望 Agent 调试在沙箱或虚拟环境中进行，不允许接触正式环境
D. 大规模运维操作不放心，一个系统可能关联成百上千台机器，担心 AI 无法全面掌握影响范围
E. 涉及内部运维操作不会交给 AI，例如 SSH 登录生产机器执行命令
F. 没有特别顾虑
G. 其他
*
*
38. Agent 辅助部署时，从打包到验证通过，通常需要人工介入几次?
A. 完全自动，无需人工介入
B. 人工介入 1 至 2 次（如确认部署目标、检查健康状态）
C. 人工介入 3 次以上
D. Agent 只能生成脚本，部署执行全靠人工
*
重构与维护 最后一个啦！
39. 您是否用过 Code Agent 辅助重构与维护工作?
A. 经常使用（每周多次）
B. 偶尔使用（每月几次）
C. 试过但放弃了
D. 从未使用
*
40. 在重构与维护阶段，您用 Code Agent 做过以下哪些任务?
[Multiple]
A. 遗留代码重构（梳理和改写老旧代码）
B. 代码债务清理（识别和消除冗余、重复代码）
C. 文档与代码同步更新
D. 微服务拆分（识别模块边界和依赖关系）
E. 大规模重命名或 API 迁移
F. 其他
*
*
41. 在重构与维护阶段，您遇到过以下哪些问题?
[Multiple]
A. Agent 对遗留系统理解薄弱，容易将关键的历史修补逻辑误判为冗余代码而删除，或遗漏隐藏在老代码中的特殊业务规则
B. Agent 分不清哪些代码该保留哪些该废弃，在代码无注释、业务逻辑复杂时尤为明显
C. Agent 生成的代码实现分散、跳转多、结构不集中，人工阅读和维护困难
D. 代码和文档双写时同步遗漏，只改了文档没改代码，或只改了代码没更新文档
E. 跨对话或跨项目的知识无法复用，之前对话中积累的设计决策和上下文在新对话中丢失
F. Agent 无法有效识别微服务拆分边界，模块间的依赖关系和耦合程度难以自动判定
G. 未遇到明显问题
H. 其他
*
*
42. 您的遗留代码库规模有多大?
A. 不到 1 万行
B. 1 万至 5 万行
C. 5 万至 20 万行
D. 20 万至 100 万行
E. 超过 100 万行
F. 没有遗留代码
*
43. 在长时间使用 Code Agent 的过程中，您遇到过以下哪些问题?
[Multiple]
A. 长对话后 Agent 遗忘早期约束或目标漂移，对话轮数多了之后最初设定的规则和目标逐渐被忽略或偏离
B. Agent 缺乏自主执行能力，无法自主完成编译、运行测试、修复、重测的完整循环，需要人工反复下达指令
C. 多模态能力不足，例如设计稿还原度低、图片编辑出错、生成数量与要求不符等
D. Token 消耗量大，成本难以控制，大量 token 消耗在项目代码阅读等非核心环节
E. 国产模型与国外模型在编码能力上差距明显，同一个任务不同模型所需对话轮次相差数倍
F. 模型排行榜排名与实际使用体感偏差大，排名靠前的模型实际体验不一定更好
G. 未遇到明显问题
H. 其他
*
*
44. 以上问题中，对您影响最大的是哪一项?
*
📋 进度：第三板块
各阶段体验已经聊完，现在做个简短的汇总，6 道题很快搞定。剩余12min。
45. 您估计使用 Code Agent 后，整体开发效率提升了多少?
A. 提升不明显（不到 20%）
B. 提升 20% 至 50%
C. 提升 50% 至 100%
D. 提升 100% 至 300%（效率翻倍至三倍）
E. 提升 300% 以上（效率翻三倍以上）
F. 反而降低了效率
*
46. 效率提升主要体现在哪些环节?
[Multiple]
A. 编码实现，代码编写速度提升明显
B. 需求设计，方案出稿速度提升明显
C. 测试，测试用例生成和执行效率提升明显
D. 调试排错，定位和修复问题效率提升明显
E. 文档生成，文档产出效率提升明显
F. 均匀提升，没有特别突出的环节
G. 其他
*
*
47. 您有意不让 Code Agent 参与的环节是哪些?为什么?
示例:"线上故障排查不让 AI 介入，担心幻觉导致误判根因"、"安全和隐私相关代码不给 AI 接触，出了问题涉及商誉和监管风险"
*
48. 使用 Code Agent 后，您的工作方式发生了哪些变化?
[Multiple]
A. 编程语言选择标准变了（会选 AI 更擅长的语言，如从 TypeScript 转向 Go/Rust）
B. 代码 review 方式变了（引入 AI 审查或多 Agent 交叉审查）
C. 测试策略变了（更依赖 AI 生成测试、TDD 流程变化）
D. 对代码质量的信任模式变了，AI 生成的代码人工阅读和维护较难，但用 AI 工具维护反而顺畅
E. 团队协作方式变了（非技术人员也能参与编码，技术栈边界模糊化）
F. 学习新技术的方式变了（通过 Agent 快速上手不熟悉的技术栈）
G. 没有明显变化
H. 其他
*
📋 进度：第四板块
针对Code Agent 您曾遇到令人印象深刻的失败案例或有好的评测思路，真诚期待您的分享。这些真实案例将直接帮助我们构建更贴合实际场景的评测基准、更好的迭代模型优化。预计剩余8min。小提示：该部分对您通过审核至关重要噢。
*
49. 请描述一个Code Agent失败的任务场景（一句话描述您在做什么）。示例:"用 Agent 给 Kafka 集群做调优方案"、"让 Agent 修改微服务的 DTO 字段重命名"
*
50. 您给 Agent 的输入是什么?（尽量还原:口头指令、贴的代码片段、文件路径等）
*
51. 您期望 Agent 产出什么?
*
52. Agent 实际产出了什么?哪里不对?
*
53. 您判断失败的根因是什么?
A. 模型能力不足（不理解业务、幻觉、逻辑错误）
B. 上下文不够（没给足项目信息）
C. 工具限制（无法访问运行环境、无法执行代码）
D. 提示不够好（换个问法可能更好）
E. 其他
*
*
54. 事后您如何处理的?
A. 手动重写
B. 换模型或换工具重试
C. 拆解需求分步重试
D. 放弃用 AI，全程人工
E. 其他
*
*
55. 如果要复现这个失败，需要准备哪些条件?
[Multiple]
A. 需要提供特定的代码文件或代码片段
B. 需要提供项目的依赖配置（package.json、pom.xml 等）
C. 需要提供数据库表结构或测试数据
D. 需要提供行业专有的业务规则文档
E. 需要搭建特定的运行环境（Docker、K8s、嵌入式板卡等）
F. 需要多个仓库或多个微服务同时存在
G. 需要特定版本的框架或中间件
H. 仅凭代码片段和指令就能复现，无需额外条件
I. 其他
*
*
56. 假设请您设计一个评测任务评测Code Agent的能力。一句话描述任务会是什么。
示例:"金融交易系统中对退款状态机的正确实现"、"跨 8 个微服务的 DTO 字段重命名完整性"
*
57. 评测任务的输入:给 Agent 什么?（请尽量具体）。示例:"提供一个包含 5 个微服务的 Java 项目（约 2 万行），其中 OrderDTO 在 Provider/Consumer/Feign 接口/Kafka 消息体/前端表单/测试/API 文档中被引用。指令:将 OrderDTO.userId 重命名为 OrderDTO.customerId。"
*
58. 评测任务的期望输出:Agent 应该产出什么?示例:"所有引用了 userId 的文件都已修改为 customerId，包括 Provider 端、Consumer 端、Feign 接口定义、Kafka 消息序列化/反序列化、前端表单字段、单元测试和 API 文档。编译通过，测试全部通过。"
*
59. 评测基准:怎么判断 Agent 做得好不好?示例:"编译通过为前提;修改完整率 = 实际修改的引用点数 / 应修改的引用点总数。完整率 100% 且测试全通过为通过;完整率 80% 以上且编译通过为部分通过;完整率不到 80% 或编译失败为失败。额外扣分项:Agent 擅自修改了与任务无关的代码。"
*
60. 这个评测用例为什么重要?它能暴露 Agent 在您所在领域的什么核心短板?
示例:"因为金融系统的退款状态机有终态保护要求，Agent 通常会简化为二元判断，丢掉 PROCESSING 和 CLOSED 两个中间态的保护逻辑，在生产环境中会导致资损。"
*
61. 您认为所在业务领域使用 Agent 比较有价值的场景有哪些？（开放，一句话描述即可）示例："投资研报检索与生成"、"不良资产建模估值"、"罕见病等特殊样例诊断"
感谢您的填写！ 下面请留下您的邮箱 等待工作人员审核联系您领取结算噢！
更多信息请浏览晓天睿士专家社区：https://www.siriser.com/siriser/home
*
联系邮箱【用于接受审核与结算通知】
字体大小
Code Agent 用户调研
复制