Back to Details

project-blueprint-builder

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Project Blueprint Builder

Project Blueprint Builder

What it does

功能说明

Turns a rough idea into a compact, implementation-ready blueprint for humans and AI agents.
将初步构想转化为一份简洁、可直接落地的蓝图，供人类和AI Agent使用。

When to use

适用场景

  • New product, app, or internal tool
  • Major feature or platform change
  • Engineering handoff or discovery package
  • Multi-step build that needs scope, architecture, and rollout decisions
  • 新产品、应用或内部工具开发
  • 重大功能或平台变更
  • 工程交接或探索包制作
  • 需要确定范围、架构及上线决策的多阶段构建项目

What to ask first

需先确认的信息

Ask only for the highest-value missing context:
  • Problem and desired outcome
  • Target users and primary user journey
  • Existing codebase or preferred stack
  • Launch scope, timeline, and constraints
  • Data sensitivity, compliance, and security needs
  • Success metric or definition of done
If the user cannot answer something yet, proceed with explicit assumptions instead of blocking.
仅询问最关键的缺失背景信息：
  • 问题及预期成果
  • 目标用户与核心用户旅程
  • 现有代码库或偏好的技术栈
  • 上线范围、时间线及约束条件
  • 数据敏感性、合规性及安全需求
  • 成功指标或完成定义
若用户暂时无法回答某些问题，基于明确假设推进，而非停滞等待。

Operating rules

操作规则

  1. Think before coding.
    • State assumptions explicitly.
    • If something is unclear, stop and ask.
    • If multiple interpretations exist, surface them.
    • If a simpler path exists, say so.
  2. Keep it simple.
    • Build only what was asked.
    • Avoid speculative flexibility, abstractions, and config.
    • Prefer the minimum code or document set that solves the task.
  3. Make surgical changes.
    • Touch only what the request requires.
    • Match existing style.
    • Do not refactor unrelated code.
    • Remove only imports or artifacts your changes created.
  4. Work toward a verified goal.
    • State a brief plan for multi-step work.
    • Define what success looks like before editing.
    • Loop until the result is checked.
  5. Pick the lightest blueprint that fits the request.
    • Lite: PRD, TRD, PHASES, MEMORY
    • Standard: add ARCHITECTURE, SCHEMA, RULES, DESIGN
    • Full: add SECURITY and MODULES for new, sensitive, or multi-service systems
  6. Use one source of truth per topic.
    • PRD = why, who, what
    • TRD = technical constraints and integration choices
    • ARCHITECTURE = system shape and data flow
    • SCHEMA = entities, relationships, and contracts
    • SECURITY = trust boundaries and protections
    • MODULES = ownership and boundaries
    • RULES = engineering standards and guardrails
    • PHASES = delivery order and exit criteria
    • DESIGN = user experience and interface direction
    • MEMORY = decisions, assumptions, open questions, and changes
  7. Prefer the current codebase, existing docs, and real constraints over invented defaults.
  8. For sensitive systems, call out least privilege, validation, secret handling, auditability, and recovery.
  1. 先思考再行动。
    • 明确说明假设条件。
    • 若有不清楚的地方，暂停并询问。
    • 若存在多种解读，逐一列出。
    • 若有更简单的实现路径，主动提出。
  2. 保持简洁。
    • 仅构建需求明确的内容。
    • 避免不必要的灵活性、抽象设计及配置。
    • 优先选择能解决任务的最少代码或文档集合。
  3. 精准修改。
    • 仅修改需求涉及的内容。
    • 匹配现有风格。
    • 不重构无关代码。
    • 仅移除自身修改产生的导入或产物。
  4. 以验证后的目标为导向。
    • 针对多阶段工作制定简要计划。
    • 在开始编辑前明确成功标准。
    • 循环迭代直至结果通过验证。
  5. 选择最贴合需求的轻量化蓝图。
    • 精简版：PRD、TRD、PHASES、MEMORY
    • 标准版：新增ARCHITECTURE、SCHEMA、RULES、DESIGN
    • 完整版：针对全新、敏感或多服务系统，新增SECURITY和MODULES
  6. 每个主题仅保留单一可信来源。
    • PRD = 原因、受众、内容
    • TRD = 技术约束与集成选择
    • ARCHITECTURE = 系统形态与数据流
    • SCHEMA = 实体、关系及契约
    • SECURITY = 信任边界与防护措施
    • MODULES = 所有权与边界
    • RULES = 工程标准与防护规则
    • PHASES = 交付顺序与验收标准
    • DESIGN = 用户体验与界面方向
    • MEMORY = 决策、假设、未解决问题及变更记录
  7. 优先参考现有代码库、文档及实际约束，而非虚构默认值。
  8. 针对敏感系统，明确提及最小权限、验证机制、密钥管理、可审计性及恢复方案。

Style modes

风格模式

Use the same blueprint structure, but tune the wording for the audience:
采用统一的蓝图结构，但根据受众调整措辞：

AI-agent prompting

AI-agent 提示风格

  • Use direct, imperative language.
  • Prefer unambiguous labels, decision points, and verification steps.
  • Keep prompts compact and easy for another agent to continue.
  • Avoid motivational prose, marketing language, and filler.
  • 使用直接、命令式语言。
  • 优先选择明确的标签、决策点及验证步骤。
  • 保持提示简洁，便于其他Agent接续工作。
  • 避免励志性文字、营销语言及冗余内容。

Human handoff

人工交接风格

  • Add just enough context for a reviewer to understand why the plan exists.
  • Make assumptions, tradeoffs, and next actions easy to scan.
  • Keep the tone practical and collaborative.
  • Highlight what changed, what is risky, and what is still open.
  • 添加足够上下文，便于评审者理解计划的存在意义。
  • 使假设条件、权衡方案及下一步行动易于浏览。
  • 保持务实、协作的语气。
  • 突出变更内容、风险点及未解决问题。

Ponytail minimalism

极简风格

  • Use the smallest useful blueprint set.
  • Remove any section that does not help the next decision.
  • Prefer one clear default over optional branches.
  • If a section can be one line, make it one line.
  • 使用最精简的有效蓝图集合。
  • 删除对后续决策无帮助的章节。
  • 优先选择清晰的默认方案，而非可选分支。
  • 若某章节可用一行表述，尽量简化为一行。

Output contract

输出规范

Create or update only the documents the request needs, in the project root or a 
blueprint/
folder. Keep the output practical and versionable, then end with:
  • assumptions made
  • open questions
  • recommended next actions
仅创建或更新需求所需的文档，存放于项目根目录或
blueprint/
文件夹。确保输出内容实用且可版本化，最后附上：
  • 所做假设
  • 未解决问题
  • 推荐的下一步行动

References

参考资料

  • Blueprint workflow
  • Templates
  • 蓝图工作流
  • 模板