Planning problem definition, architecture decisions, evals, launch, and retrospective templates.
Build & Validate / Engineering & Operations Overall Framework ↗
Table of Contents for This Page
How to Use the Templates
Templates are meant to drive decisions and preserve evidence, not to fill in blanks. Each document has a version, owner, review status, date, and evidence links; items not yet verified should be marked "pending verification," and it is forbidden to fill in "passed" in advance. The templates below can be downloaded directly; fill in synthetic examples or replace them within an authorized environment.
Template Directory and When to Use Them
| Template | When to Use | Minimum Questions It Should Answer |
|---|---|---|
| One-Page Problem Definition | Before kickoff | What problem for whom, what is the evidence, what is excluded |
| Architecture Decision Record (ADR) | Key design | Options, evidence, trade-offs, and re-review conditions |
| Prototype Experiment Log | Technical validation | Hypotheses, controls, stopping conditions, and conclusions |
| Metrics and Evals Plan | Before pilot | Denominators, samples, thresholds, scoring, and versions |
| Launch Checklist | Before release | Whether permissions, degradation, rollback, and responsibilities are verified |
| Acceptance and Handover Record | At handover | Who takes over, whether recovery is possible, how open items are closed |
| Incident Retrospective | After recovery | Impact, timeline, root cause, improvements, and re-testing |
Example: How to Fill In Evals Evidence
对象：售后回复草稿 v0.1（合成示例） 样本：evaluation-seed.json，20 条教学种子 当前验证：离线关键词检索与版本/租户过滤 尚未验证：模型生成、引用忠实度、真实身份与缓存撤权 结论：可用于课堂演示，不构成生产验收通过 下一步：扩充样本并接入真实权限与模型回归
Evidence Organization
It is recommended to organize the project directory by problem, design, implementation, evaluation, release, handover, and retrospective. File names should include the object and version, evidence should use relatively stable addresses, and beyond screenshots, keep inputs, outputs, configurations, and test methods.
Public repositories should only contain synthetic or approved, de-identified materials. Real acceptance signatures, customer logs, and account information stay in authorized systems; public templates retain only structure and examples.
Review and Maintenance
Review whether the templates help make decisions: a missing owner means no one will take responsibility; no failure threshold means nothing can be blocked; no evidence means nothing can be re-verified. After a project ends, delete unused fields and add judgments for things actually missed, but keep historical versions to explain decisions made at the time.
Further Reading and Usage Boundaries
- GitHub Actions Official Documentation: extended reading on related concepts and methods, access verified on 2026-10-14. The exercises, workflows, and metrics on this site are independently organized and are not certified by the source organization.
- Learning Path · Project Practice · Downloadable Templates
This page is a basic guide; production operations must be verified against actual versions, authorized environments, and review evidence.