前言
很久前就想开一篇文章记录了，主要是太懒了。本来想让AI写，但是AI写的东西味又太重了。
还是自己写有一些活人感和实在感。
为啥不叫
Vibe Coding呢，因为我这个对于所谓Vibe没有特别大的感悟，还是称为AI Coding好一些。
一些小经验
主要还是使用matt pocock的技能工作流，目前看来效果还是相当不错的。
在仓库中先使用setup技能，搭建agent基础工作流环境和文档，创建AGENTS.md等文件，有助于agent理解项目和工作规则。
对话过长上下文污染，需要开启新会话，但是会导致已有内容丢失，需要对已有工作留档。
使用grill-me技能确定需求，效果还好，在一定程度上可以补全未考虑完善的地方。但是容易陷入无限询问，而且偏向细枝末节的地方。
to-spec技能帮忙落实文档，会确立项目简要目标和基本信息，也会从多种用户角度提出需求。但是有时过于简洁，容易丢失一些关键需求内容。人工审核的时候，仔细阅读的话又十分费劲，毕竟AI的输出实在是太多了。
to-tickets技能拆解需求，形成实现的具体步骤清单，且具有依赖顺序的拓扑图，可以按照依赖关系逐个实现。但是并没有按模块划分，只是按需求划分，容易使得实现混乱。此外，在同一对话进行多个工单实现，容易上下文暴涨，效果越来越差。应该尽量保证对话干净，一个对话最好只进行一个工单任务。
每次让AI干活前，先保存一下本地工作，如果AI做错了，直接版本回滚就好。
实现代码工作时使用implement技能：该技能会在代码修改后执行两个子agent进行审查工作，一个审查spec，一个检查standards，也即检查是否有实现需求，以及检查实现的代码是否遵守项目规范。如果不合规则会继续返工修改，这样可以提高ai产出的代码质量。
先确认后操作：每次操作先输出修改计划和可能会涉及到的文件等，确认后再执行，提高coding的掌握感。每次涉及到代码修改等开发工作前，使用plan模式，或者在AGENTS.md里添加规则，要求agent先输出修改的目标和会涉及到的文件，仔细阅读确认后再开始执行，可以减少很多问题。
最好为项目建立索引文件index，简要指明项目结构和文件，可以提高agent对项目的理解，提高目标文件和代码的检索速度和准确度，同时记录了项目代码的实现和设计细节，在重构时可以作为重要依赖。让AI在完成工作的时候及时更新index，也有助于我们了解AI对项目的修改情况。index也最好采用渐进式披露，使用主索引和子索引结构，主索引按模块或功能划分，指向各个子索引文件，子索引文件则记录每个模块详细的内容。
原型探索时，尽量以核心功能为，以跑通功能为目标，避免涉及边缘和过于细节的功能，这样可以减少代码量，从而避免项目混乱。当功能跑通后，再慢慢加细节和优化。
善用goal模式：如果要执行一个长流程多步骤任务，或者希望一次会话完成多项任务，可以启用goal模式，这样agent可以在每次执行完后检查是否完成目标，如果没有则会继续执行下一步，不用人工确认。不过前提还是要和agent做好充足的讨论和方案确认，再开始goal，不然最后可能得到不如意的结果。
保持心平气和。AI可能会很傻，改少一些东西、没有同步一些东西、重复写了一些相同或冗余的代码、重复犯相同错误。但是可能本质都是上下文信息不足而已。所以建立好一个上下文系统，才能让AI完整理解项目内容，减少犯错的概率。
待解决问题
如何并发同时进行多个开发任务
每次开一个新对话，怎么快速补全项目上下文？暂时采用
AGENTS.md + CONTEXT.md + project-index如何进行AI Review？
实践工作流（持续更新）
理想的工作流：确定需求-模块化拆分-分模块落实需求文档-模块文档转实现步骤工单-按模块依次执行工单-测试验收
在使用matt pocock的技能工作流之前，需要使用setup技能，初始化项目的文档配置，
工作流一（适合需求量少的情况）：
grill-me/grill-with-doc：通过多轮对话确立需求，但是要根据颗粒度使用，对于项目级别，确立主要需求和各个模块；对于模块级别，确立实现细节。
to-spec：新立项时，先确立对整个项目的需求，然后落实项目级别需求文档，并拆分多个模块；之后确立多个模块的具体实现方案，分别落实文档。
to-tickets：根据to-spec确定的需求，多次使用skill，分别对各个文档确立实现工单。
implement：根据ticket和项目信息进行开发任务，会在工作中启用两个子agent进行双检验测试。
工作流二（大模块或实现思路模糊）：
wayfinder：必备核心skill，可以理解为grill的升级版，会协助我们理清需求并落实到多个拓扑ticket，构建成一张map，完成map也即完成了整个需求的开发。ticket包括grilling、search和task三种类型，分别进行需求询问和确认、调研搜索相关信息（调研技术栈、实现方案等）以及具体的开发任务。
依次wayfinder：对于grilling和search类型的工单，可以继续使用wayfinder进行落实。在完成grilling的时候，可以使用to-ticket转成任务工单。
implement：对task ticket进行开发任务，由于具备了map以及其他相关需求上下文，此时进行代码开发会具备完善的信息，往往实现的质量更高，也更符合需求。
总结
说到底都是软工的问题。只有掌握软工基本功和架构设计能力，才能真正驾驭AI coding。
此外，ai工作成果的好坏，很大程度取决于上下文的质量，因此维护好上下文是重中之重。
