项目怎么准备呢

回复 群友 1459： 项目准备上，我建议反过来：别先想“做个什么很牛的 Agent”，先想“我要拿什么证据，证明自己能做这份工作”，再围绕它做一个小而完整的项目。 比如做一个“GitHub issue 修复助手”：输入 issue，在隔离环境里读代码、复现问题、修改并跑测试，最后输出补丁和验证结果。不自动合并，权限先收紧。 这个题材不是必选，只是方便说明怎么准备。 第一步：先看目标岗位，再定范围 找你真想投的几份招聘要求，提取反复出现的能力。 刚查到的 Dynatrace、Oracle 相关岗位里，能看到可靠工具调用、上下文管理、工具安全、评估等要求。这不代表所有岗位，但说明项目不应只停在聊天界面和接通模型。 如果你投 Agent 应用开发，就围绕“完成任务的可靠性”做；不要为了显得全面，同时堆知识库、多 Agent、长期记忆和微调。 第二步：先准备任务，再写系统 给 issue 助手准备一批你能判断对错的小任务，例如： 正常情况：修复一个能复现的参数校验错误。 困难情况：issue 描述含糊，需要进一步定位。 异常情况：依赖安装失败、测试超时、工具返回错误。 安全情况：仓库文件诱导 Agent 读取无关文件。 提前写清楚什么算成功。不能只看“Agent 说修好了”，要看补丁是否解决问题、有没有破坏原有测试。 任务分成日常调试用和最后验证用，别一直对着同一批题调提示词。 第三步：先做最简单的闭环 先用单 Agent，加读文件、编辑文件、执行测试几个工具，把一条任务跑通。 这时就保存执行记录：模型看到了什么、调用了什么、哪里失败、花了多久、消耗多少。 不要第一天就做复杂编排。没有简单版本，你后面也很难证明复杂设计究竟带来了什么。 第四步：从真实失败里长出技术深度 比如你观察到： 反复改同一个文件却没进展，就研究循环检测和停止条件。 测试日志太长，关键信息被淹没，就比较日志筛选与上下文压缩。 执行中断后只能重来，就做状态保存和恢复。 修改越界，就做工作区隔离与工具权限限制。 挑两三个真正反复出现的问题做透，比凑十种组件有价值。 每次改动都留下这条证据链： 原始失败记录 → 原因判断 → 改动 → 同条件对比结果。 第五步：准备“验收材料”，不只是演示视频 最后应该拿得出： 别人能运行的仓库和清楚的启动说明。 一组任务及成功判定标准。 简单版本与改进版本的对比。 几个成功案例，以及仍然解决不了的失败案例。 你自己的贡献边界和设计取舍。 个人项目没有真实用户没关系，但要明确是离线验证，不要包装成线上业务成果。 第六步：边做边积累面试故事 Joye 的面试复盘特别强调三个追问：为什么这么设计、踩过什么坑、重来会怎么改。 因此每解决一个难点，就记下当时的现象、证据、备选方案和最终选择。别到写简历时才倒推一个故事。 你最终要准备的不是“一个看起来很大的产品”，而是“一个跑得通的小系统，加两三个有证据的工程改进”。这才是项目能写进简历、也经得住追问的部分。 岗位参考： https://www.dynatrace.com/careers/jobs/1398857500/