AI-NATIVE DEVELOPMENT FRAMEWORK.
我们把原本由人运转的工作，变成了AI能够准确运转的模式。
我们把作为开发公司积累下来的市场营销和产品开发工作，转化为AI工作流和技能。
AI执行，人来判断。借助这套机制，我们以组织的方式运转AI开发。
MARKETING WORKFLOW.
我们把媒体运营的PDCA，整个做成了AI技能。
从设定目标、每日报告、任务化、制作，到发布后的评估，我们把全过程作为一个循环来运转。
我们把这个循环的各个环节转化为AI技能，并自主开发、运营CMS“Autorial”，作为运行这些技能的基础平台。
根据报告创建工单并进行处理的是AI。人则接收变更报告并进行确认。
不过，文章等特别重要的内容会指派给人，由人集中精力完成。
FIG. 01-A
媒体运营循环
7个环节由AI技能和CMS“Autorial”运转。浅蓝色的环节由人判断。
FIG. 01-B
从报告到工单，再到处理
AI根据报告创建工单并处理，人确认变更报告。文章等重要内容指派给人。
分步说明
01 — GOAL
设定目标
根据事业目标，确定要追踪的指标和报告的形式。
由人判断
02 — REPORT
每日报告
每天将SEO调研和数据变化整理成报告。
03 — TICKET
AI生成工单
AI根据报告中的数据变化，把应对措施写成工单。
04 — CREATE
处理与制作
AI处理工单，推进创意素材和文章的制作与审核。文章等重要内容会指派给人。
05 — CHECK
核对规范
发布前，对照医疗广告指南等法规进行检查。
06 — PUBLISH
发布并观察反馈
发布后，检查用户的反馈。
07 — CONFIRM
确认与评估
由人接收变更报告并确认，对照目标进行评估。
由人判断
回到01 目标，循环持续运转
TICKET DRIVEN DEVELOPMENT.
我们把项目经理的工作，融入了工作流。
工单管理、需求定义、开发时的用户故事整理。以往由项目经理负责的领域，我们几乎全部交由AI工作流来运转。
外包开发公司投入人力最多的，是把需求和设计写成工单和文档的工作。我们把它融入工作流，杜绝了工单已更新、文档却还是旧版的情况。
任务看板则根据产品需要，扩展使用Notion或我们自己的看板等。
其中最难的是QA真机测试。我们在背后建立了一套知识Wiki，汇总如何操作每个服务，定义网站的规格和操作方法。正因如此，AI才能实际操作服务并进行测试。
另一道难关是：交给AI的QC，确认了什么、怎么确认的，很难留下记录。为此我们开发了管理浏览器QC证据的内部工具“koma”。它把AI在浏览器中进行的操作，按每个操作记录为截图和确认项，事后可以回放并共享。QC的操作作为测试用例留存，直接延续到下一次QC。
在外包开发中，最大的瓶颈正是这种浏览器QC。从工单和文档、实现，到QC的证据，全部作为一条连续的记录留存，负责评审的人可以逐帧追溯确认了什么、怎么确认的，再做判断。这就是我们作为AI外包开发范式所掌握的机制。
支撑这套工作流的不只是AI的性能，而是我们建立规范、并在日常业务中量化运转所积累的经验、诀窍和实绩。
FIG. 02-A
工单的推进方式
一张工单在看板上推进，从创建、QA直到完成。
FIG. 02-B
分支策略
每张工单创建一个工作分支，通过PR合并回开发分支进行QA，合并到生产分支即完成部署。
FIG. 02-C
工单与文档同步
更新工单时文档也随之更新，代码则按照文档编写。
FIG. 02-D
支撑真机测试的知识Wiki
网站的规格和操作方法都定义在Wiki中，因此AI能够实际操作服务并进行测试。
FIG. 02-E
用koma留存QC证据
把AI的操作按每个操作的截图和确认项记录下来，回放并共享。QC的操作作为测试用例延续到下一次QC。
分步说明
PLAN — 规划
01ICEBOX创建把需求转为工单
客户的需求和我们发现的问题，首先全部变成工单。不停留在口头或聊天里，一切从留下记录开始。
这个环节要做的事
把需求转为工单
AI把会议和聊天中提出的需求转为工单，不会出现“说过没说过”的问题。
确定需求
明确做到什么程度才算完成，确定需求和完成条件。
整理用户故事
整理这个功能是谁、为了什么而用，把开发的理由留在工单里。
- 02TODO待开始
整理到可以着手的状态
较大的需求先拆分成可以动手的大小，再决定下一步做什么。
这个环节要做的事
拆分任务
一张工单太大时，拆分成便于实现的单位。
估算工作量
估算工作量，尽早发现与进度的偏差。
决定顺序
根据对业务的影响和紧急程度，决定着手的顺序。
BUILD — 开发
03IN PROGRESS进行中先改文档，再动手开发
开始作业后，把状态改为进行中。先更新文档，再按照文档实现。
这个环节要做的事
创建工作分支
每张工单创建一个工作分支，避免与其他变更混在一起。
更新文档
先更新规格和设计文档，消除工单与文档之间的偏差。
实现
按照更新后的文档编写源代码。
- 04DONE开发完成
机器能检查的，全部检查
实现完成后，先通过所有能自动检查的项目，再提交评审。
这个环节要做的事
代码检查
通过类型检查和Lint，消除书写错误和类型不一致。
构建测试
确认按与生产环境相同的步骤能够构建成功。
创建PR
创建说明改了什么、为什么改的拉取请求。
- 05MERGED合并
发布到可以实际操作的环境
通过评审的变更合并到开发分支，发布到可以实际操作画面的环境。
这个环节要做的事
评审
确认变更内容是否符合工单的需求。
发布到开发环境
合并到开发分支后，开发环境随之更新。
准备确认画面
通过确认用的URL，查看与生产环境一样运行的画面。
TEST — 验证
06QC质量验证实际操作，逐一确认
这是最费工夫、最需要诀窍的环节。AI依据知识Wiki，在浏览器和真机上实际操作服务进行测试。
这个环节要做的事
查阅知识Wiki
阅读汇总了网站规格、页面与动线、操作步骤和测试要点的Wiki，决定操作什么、怎么操作。
浏览器测试
在真实的浏览器中打开页面，逐一确认显示和操作。每次操作都把截图和确认项记录到koma中。
真机测试
在智能手机等真机上也同样操作确认。
- 07QC OK验证通过
把结果和证据一起留下
测试结果汇总成QA报告。发现问题就退回进行中修复。
这个环节要做的事
汇总QA报告
列出确认了什么、结果如何。QC的操作留作测试用例，下次QC继续使用。
用koma留下证据
把每个操作的截图和确认项留在koma中，任何人事后都能回放确认。
NG退回
缺陷附上复现步骤退回进行中，修复后再次测试。
RELEASE — 发布
08PM REVIEWPM评审由人查看，决定是否发布
最终判断由人来做。查看AI提交的报告，决定是否可以发布。
由人判断
这个环节要做的事
对照需求
确认完成的内容是否符合最初的需求和要求。
确认报告
确认QA报告并回放koma中的证据，有疑问就退回。
决定发布
包括发布时机在内，决定是否可以发布。
- 09DEPLOY部署
发布到生产环境，持续守护
合并到生产分支完成部署，并在生产环境确认运行正常。运营与监控从这里开始。
这个环节要做的事
部署到生产环境
通过合并到生产分支，按固定步骤部署。
生产环境测试
在生产环境中确认主要操作能正常运行。
开始监控
导入存活监控、内部监控和外部监控，移交给运营。
移交至03 运维与监控
OPERATE FROM DAY ONE.
从部署的那一刻起，监控与运营就开始了。
在部署并投入生产环境的那一刻，我们就为所有产品统一导入存活监控、内部监控和外部监控。
出现告警时立即处理；如果是轻微故障或服务器错误级别的问题，我们采用自动修复的机制。
维护、运营、监控、开发等日常业务，开发公司承担的所有工作，我们都已转化为工作流和技能。
FIG. 03-A
监控与自动修复
通过3种监控持续关注生产环境，轻微故障自动修复。
分步说明
01 — LAUNCH
投入生产环境
部署的同时，统一配置监控。
02 — MONITOR
监控
通过存活监控、内部监控和外部监控，持续确认服务有没有停止、有没有变慢。
03 — ALERT
发出告警
检测到异常时，发出告警并着手处理。
由人判断
04 — AUTO-FIX
自动修复
如果是轻微故障或服务器错误级别的问题，会自动修复。
持续监控，并衔接到下一轮开发
WHAT CHANGED
LESS DRIFT. FASTER PAYBACK.
按计划推进，成本相称，回收更快。
我们本来就是一家开发公司。
我们让原本由人运转、业务成本很高的工作，通过工作流准确地运转起来。
因此，我们现在能够提出进度和预算都更容易预估的产品开发方案。
- 01 — ON SCHEDULE
与计划的偏差小
意外返工造成的进度延误和偏差，我们现在能控制在最低限度。
与原定开发内容之间的偏差也变少了。 - 02 — RIGHT COST
成本与产品相称
现在，一位值得信赖的总监就能统筹整个项目。
与投入大量人手相比，能大幅降低开发成本，因此我们能提出收益与成本平衡良好的方案。 - 03 — FASTER PAYBACK
投资回收快
从做出决策到产出下一个成果的周期很短，能更快推向市场。
越早推向市场，初期投资回收得也越快，也就更容易投入预算。