通过前面几篇介绍我们对 JetBrains AI 的能力范畴有了大致了解。Junie 是不会主动删除文件的，即使已经没有再引用的必要。如果对话超过五轮仍然没有得到想要的结果，那可以考虑重新开始一个对话。同样的，如果提供的方案没有解决问题并且一直在循环，那也要重新开始一个对话，并思考下是不是没有提供充分的上下文知识，还是没有清晰定义问题。
现在进一步探讨下如何辅助开发新需求。
无论是以瀑布模式为代表的传统软件工程，还是近二三十年以敏捷为代表的现代软件工程都强调设计先行的重要性，也就是执行编码任务之前先做规划。编码只不过是将软件转换成可执行形式，它背后是一整套软件知识管理，如果做不好知识管理，通过一句话让 AI 自行理解并生成代码就是妄想。
Junie 提供了编码生成三部曲，通过结构化的需求分析，到结合项目背景的执行计划，再到拆分成具体任务的清单，最后生成代码不过是水到渠成的事情。
1、需求分析
考虑一般到 Java 项目体量，需求分析无法缺省。不管是复杂需求分析还是简单需求描述，Junie 可以帮助维护一份需求分析文档，这是整个代码维护的源头。
如果是来自 PRD，可以借助一些支持文件解析并且支持超长输入的大模型辅助提取需求功能点，包括文件中包含的图片、表格等形式，比如 Gemini，Grok。
需求文档手动创建在项目根目录 /docs 下。需求文档重在逻辑连贯，描述清晰。在 Junie Livesteam 直播中，就给出了这样的需求描述示例，同样可做参考：
-
New features to be implemented（待实现的新功能 ）
-
Replace legacy Java implementation with a corresponding Jarvis match implementation in Kotlin（用 Kotlin 中相应的 Jarvis 匹配实现替换旧的 Java 实现 ）
-
Implement structural change: extract algorithm selection into a service. The algorithm should be selected by name using a request parameter（实施结构变更：将算法选择提取到一个服务中。应使用请求参数按名称选择算法 ）
-
Add persistence for computations（为计算添加持久性 ）
2、制定计划
使用大模型辅助编码已经形成一种最佳实践，在直接生成代码之前先生成设计思路，这样有助于和大模型对齐任务理解，避免认知差异以及无端的 token 消耗。对于 Junie 来说同样如此，而且作为产品设计的一部分成为与 Junie 的交互约定。下面就来结合示例介绍下如何让 Junie 生成代码之前对齐执行计划。
Junie 在内置的模板中也提供了，可以一键触发：
阅读“docs/requirements.md”文件，提取关键目标和约束条件，并为项目创建详细的改进计划。该计划应描述每项拟议变更的理由，并保存到“docs/plan.md”文件中。使用清晰的章节标题，按主题或系统领域组织计划。
这样做的好处就是避免 Junie 乱发挥，在需求文档和 Guidelines 的约束下分解需求，形成功能处理流程、数据库设计、接口设计等。
实现效果是这样的：
3、任务拆解
执行计划大概相当于概要设计，任务拆解大概相当于详细设计，深入业务与架构后做出可行的任务列表。
这一步是否需要生成代码视情况而定，需求首次生成可以生成关键代码，如果是需求修改就不用再生成了。做到这一步就真的像是给实习生布置开发任务，实习生只要根据任务一个个完成。
根据
docs/plan.md创建一份详细的可操作的编码任务列表，并将其作为清单保存到docs/tasks.md，每项任务都以占位符 [ ] 开头，完成后标记为 [x]。
使用 markdown 完成标记的好处是能够记录整体进展，便于 Junie 及时核查。
任务拆分会花费较多时间，也很有可能发生这种超出窗口上下文的情况。可以考虑按章节分批进行，按照执行计划章节分成多个 Junie 任务并行完成。
4、编码执行
最后，就是按照任务列表编码了，Junie 同样内置了编码模板。
根据
docs/tasks.md中的任务列表，迭代实施改进。完成每个任务后，将复选框从 [ ] 更改为 [x]，将其标记为已完成。确保每项更改均符合.junie/guidelines.md中的样式指南以及docs/plan.md中的改进计划。
同样的，也建议按照任务章节分别执行，否则容易信息过载。
5、编码审查
在所有 Junie 任务完成之后，还需要花一些时间做代码审查来善后，非常有必要。
- 初步消化代码，了解 Junie 编码风格，如果不妥需要及时修改并补充到 Guidelines
- 保持代码熟练度，即使充分设计，Junie 也不是自动驾驶，很难避免理解不了或难以传递的任务，这时候仍然需要上手处理
- 负责最后一公里，Junie 在很多简单任务中表现出色，即使可用度达到 90%，程序员也需要最终负责
