AI-NATIVE WORKFLOW SYSTEMS
Three systems examine AI across production, collaboration and delivery. Each began with a real friction, then moved through observation, research, prototyping and repeated use. The goal is not to hide judgment, but to make hidden work visible, reusable and easier to act on.
三个项目不是三个孤立的 AI Demo，而是三次从真实工作断点出发的系统化实践：华建处理设计生产，DesignOps 处理跨角色协作，Website Skill 处理个性化交付。共同点不是“都用了 AI”，而是先找出人正在重复承担的隐性判断，再决定哪些部分适合被结构化、自动化，哪些判断必须留给人。
The three systems start in different places, but share one method: find the recurring breakdown, trace the missing information or judgment, then design the AI layer around the real task.
我没有先决定“做三个 AI 产品”。华建从真实效果图返工中长出来，DesignOps 从 Amazon 的排期与沟通摩擦中长出来，Website Skill 从真实付费网站交付中长出来。三个项目分别把生产、协作和交付里原本隐性的工作重新变得可见、可解释、可复用。
Translate model complexity into design-task language, then carry structure, revision and team knowledge across rounds.
差异点 / 不是更强的生图器，而是团队可用的 AIGC 工作层
Make the conditions behind a deadline visible: brief completeness, capacity, risk, revision reasons and ownership.
差异点 / 不是自动排日历，而是承诺前的协作解释层
Turn positioning, project weighting, style judgment and QA into a repeatable worktree validated through paid delivery.
差异点 / 不是模板建站，而是把内容与审美判断产品化One method, applied to a real production workflow.
SYSTEM 01 / REAL-WORLD AIGC WORKFLOW
This workflow did not begin as a platform idea. It began with real landscape delivery work at Huajian: waterfront bridges, wetland scenes, architectural nodes and public spaces where the original design structure could not be casually changed. AI accelerated the first image, but repeated revisions exposed a deeper gap: requirements had to be translated again, structural fidelity could drift, successful settings were hard to recover, and more outputs created more review work. The differentiator is therefore not a stronger image model, but a team-ready layer that connects task language, structural boundaries, revision context, comparison, cost and reusable knowledge.
这个项目并非从“做一个 AI 平台”开始，而是起于华建集团 · 现代建筑规划设计研究院真实景观项目的效果图优化与汇报交付。我在连续处理鸟瞰、桥梁、湿地、建筑节点与开放空间时发现：AI 已经把“第一张图”变快，但真实交付仍被需求转译、结构校正、多轮修改、方案筛选和经验丢失拖住。于是我没有再做一个“更强的生图器”，而是把模型、Prompt、参考图、参数、比选、成本和复用重新组织成一条设计师能直接理解的任务链。真正的命题变成：不是让设计师先学会 AI，而是让系统先理解设计任务。
I was initially optimizing report-ready renderings, not designing a product. But after the same failures repeated across bird's-eye views, bridges, wetland scenes and architectural nodes, I started treating everyday production as research evidence: what must never move, what can be visually optimized, what information disappears between rounds, and why a successful result is difficult for another person to reproduce.
实习初期，我真正做的是效果图交付。第一周我就在区分“不可改变的方案信息”和“可以优化的视觉信息”；随后又发现 AI 会过度理解“高级感”“商业感”等模糊要求，甚至自动增加水景、构筑物或装饰。批量出图后，问题进一步暴露：每张图重新分析、重新写 Prompt、重新校正结构，即使单张生成很快，整个项目仍被重复判断拖住。于是我开始记录失败点、版本原因和处理方式，把日常出图反过来当成研究材料，追踪真正丢失的是哪一段信息，而不是把所有失败都归因于模型能力。
Information arrives as drawings, annotations, references and spoken feedback before it becomes an executable brief.
设计师说的是任务语言，而不是模型语言。“保持原方案”“植物更自然”“雨后但不要过度电影化”本身已经包含专业判断。系统需要把这些信息拆成目标、Must Keep、可调整项和风格边界，再转成可执行 Prompt，而不是把 Prompt 工程成本继续留给使用者。
A visually attractive result is unusable when bridges, buildings, water systems or scale relationships are changed.
真实汇报里，“更漂亮”但改了桥位、建筑轮廓、水系或尺度关系仍然是失败。结构保护必须先于风格自由度，因此系统把 Must Keep 前置，并在继续优化时继承上一轮的结构约束，避免每次修改都重新校正。
More outputs create more review work when their differences, paths and implications remain invisible.
生成数量上升后，瓶颈从“有没有图”转向“怎么判断”。团队真正需要的是同时看见方案差异、生成路径、修改依据和继续优化成本，所以结果区从 Gallery 被重新定义为支持比选与讨论的 Decision Surface。
Prompts, model usage, costs, failures and successful methods remain personal unless the workflow records them.
只保存最终图片，会把真正有价值的方法丢掉。系统同时记录模型、Prompt、参考图角色、调用与余额、失败原因和适用条件，让“这张图怎么成功的”可以被解释、搜索和复用，把个人手感逐步变成团队资产。市场上并不缺强大的生成工具。真正缺的是中间这一层：把节点、模型和参数翻译成设计任务，同时让景观设计师能低门槛进入、项目负责人能比较和判断、内部 AI 协作者能管理模型与成本。这个“翻译层 + 连续工作流”才是平台的核心价值。
I stopped treating “the user” as one person. The same workflow is judged differently by the designer who wants speed, the project lead who owns delivery quality, and the AI collaborator who maintains the technical stack.
这不是一个“设计师工具”就能概括的问题。同一套系统要同时通过三种判断：设计师愿不愿意用、负责人敢不敢拿结果去汇报、内部 AI 协作者能不能维护。因此设计重点不是一味简化，而是把复杂度分层：对设计师翻译成任务语言，对负责人翻译成差异与风险，对维护者保留模型、成本和文档治理。
我想快速看到几个方向，但不想先学习节点、LoRA 和 ControlNet。
01从场景、目标和参考图开始，而不是从模型名称开始。
DESIGN RESPONSETemplates + Basic Mode建筑关系不能动，但氛围、材质和汇报方向需要快速比较。
DESIGN RESPONSEMust Keep + Compare
02我需要多个可汇报方向，也需要知道差异和修改代价。
本地部署与模型控制很重要，但复杂度不能原样交给设计师。
03模型、算力、成本与安全要可维护，前台又不能过度技术化。
DESIGN RESPONSEGovernance + Documentation真正需要设计的是一条能够翻译需求、隐藏复杂度、保留控制并沉淀经验的工作流。
同一条路径同时服务非技术使用者、项目决策者与内部维护者。
Five evidence streams were used to separate three different causes that are easily混在一起: model limits, unclear input, and broken workflow continuity. The goal was not to prove a platform idea, but to find where information disappeared and where human judgment was still essential.
研究并不是先画界面再寻找理由。我回看真实图纸、模型、批注、参考图、Prompt、生成结果和版本记录，走查从收到需求到汇报后的完整路径，再用工具对照与多轮生成测试判断：哪些问题真的是模型能力限制，哪些其实来自输入太模糊，哪些来自上一轮约束、修改原因和成功方法没有被继续带下去。最终研究回答三个问题：信息在哪里丢失？哪些控制必须保留但不该直接暴露？哪些判断即使有 AI 仍必须由人负责？
回看真实图纸、模型、批注、参考图、Prompt、生成结果和汇报要求，确认哪些信息在转译和修改中开始丢失。
从收到需求到汇报后再次生成，问题贯穿输入、选择、修改和复用，而不只发生在生成按钮。
通过使用者沟通、任务流程走查与试用反馈，整理角色差异、问题维度和核心洞察。
比较 ComfyUI、SD WebUI 和在线生成工具在本地部署、结构控制、学习成本、连续性、复用和可解释性上的差异。
对比自由输入与结构化输入、Basic 与 Pro、单图与多方案、无记忆与跨轮次保留。
ComfyUI already offers powerful node-based control and local workflows; online tools already offer fast entry. This project does not try to replace either category. It focuses on the missing team layer between them: task-language entry, structural boundaries, continuous revision, decision support, reusable knowledge and model/cost governance.
这里比较的不是“谁的模型更强”，而是“谁更适合研究院团队长期使用”。节点式工具强在自由度和控制，在线工具强在低门槛；我的方案补的是二者之间的团队可用层。下方数值仅用于定性展示各类方案的相对能力轮廓，不是实验评分或市场排名。
CURRENT READING
技术能力被翻译成任务语言，同时保留专业控制、状态反馈和团队记忆。
The research did not produce a feature wishlist. It produced four workflow rules, and every feature had to justify itself against one of them.
这里真正想展示的不是“四个功能”，而是四条比功能更稳定的产品原则：结构是硬边界、参考图必须有角色、修改必须继承上下文、结果必须支持汇报与团队决策。功能只是这些原则在界面里的落点。
已确认的桥位、建筑、水系和构图关系是不可越过的边界。
HOVER TO REVEAL RESPONSE
默认从目标、主图、必须保留项和可调整项开始，而不是直接选择模型。
参考图只影响氛围、材质和风格，不能替换主体结构。
HOVER TO REVEAL RESPONSE把主图、参考图、批注图、风格图和彩平图拆成不同输入角色。
批注意图需要被系统理解为约束，而不是被直接生成到画面中。
HOVER TO REVEAL RESPONSE
每轮修改继承上一轮的上下文、失败原因和必须保留项。
最终输出要满足项目沟通和汇报标准，而不只是视觉探索。
HOVER TO REVEAL RESPONSE把结果、生成路径、修改依据和成本记录转化为可讨论的决策界面。
Each version corrects a wrong assumption about where the real bottleneck was. V0 believed better prompts were enough; V1 proved structured input still exposed too much complexity; V2 lowered the entry barrier but revealed a new bottleneck in comparison and revision; V3 finally connected generation to decision and memory.
这四版不是视觉迭代，而是问题理解逐步变深的过程。向下滚动查看每一次“假设 → 失败 → 决策”如何把系统从 Prompt 工具推进成连续工作流。
假设 Prompt 写得足够好就能提效；实际高质量结果仍依赖个人经验，每轮几乎重新开始。
把场景、目标、参考与保留项变成字段后连续性提高，但参数复杂度仍然暴露给非技术用户。
Basic 降低首次使用成本，Pro 只在复杂任务时展开；随后发现新的瓶颈已经转向方案选择和修改。
生成变快后继续向后设计：连接 Compare、Revision Notes、Version Memory 与 Archive，让结果可以被判断、恢复和复用。
高质量输出依赖个人 Prompt 经验，无法稳定复制。
先组织场景、参考与约束，再进入生成。
结构化输入提高连续性，但参数仍让非技术用户退缩。
默认使用任务语言，专业参数进入二级控制。
Basic 适合探索，复杂任务仍需要结构控制。
按需展开 Pro，并解释参数如何影响结果。
方案变多后，瓶颈转向判断、修改和复用。
加入 Compare、Revision Notes、Version Memory 与 Archive。
首轮生成只是起点。最终系统把方案生成、风格收藏、模型与余额、工作流画布和使用设置组织成五个连续页面。右侧保持完整画幅，自动播放，也可点击缩略图快速查看每一页解决的具体问题。
这个项目始于华建 AIGC 实习中的一个反差：首轮出图已经很快，但每次修改仍像重新开始。于是我先追踪信息在哪里丢失，再把真实任务、角色拉扯、工具比较与多轮测试转化为五个关键界面。右侧大图会自动轮播，也可以点击缩略图快速查看每个页面解决了什么。
优势是先把目标、主图、参考和必须保留项拆清楚，让第一轮生成不是盲试，而是带着项目边界进入探索。
The strongest outcome was not another interface, but the shift from individual AI skill to a method that other people could understand, discuss and continue using.
这个项目的优势最终落在“可迁移”上：把原本依赖个人 Prompt、工具熟练度和视觉直觉的操作，沉淀成任务语言、结构边界、版本记录、比选与知识资产。它获得内部 AI 专家的认可与协作，并在景观团队实际协作范围内继续使用和迭代；结果不包装为公司级全面上线。
基于个人任务记录与试用反馈，首轮方向探索被压缩到分钟级。
从 Manual Prompt 到 Structured Intake、Basic/Pro、Compare & Memory。
模型、Prompt、模板、文档和适用场景在实习后继续被维护。
获得华建集团内部 AI 专家的认可与协作，并由景观团队持续沿用和优化。
SYSTEM 02 / DESIGN SCHEDULING & COORDINATION
A design-specific coordination prototype shaped by real request friction during my Amazon internship and developed with teammates for an online Beijing AI hackathon. The key insight was that a deadline is not just a date: it is a commitment built on brief completeness, capacity, priority, revision history and decision ownership. The differentiator is not a smarter calendar, but an explainable layer before the promise is made.
项目从 Amazon 高频设计协作中的真实摩擦出发：需求方想尽快知道“什么时候能给”，设计师却常在 Brief 不完整、当前负载不可见、确认责任不清的情况下先被要求承诺时间。于是我把“排期工具”重新定义为“承诺前的协作解释层”：先把不确定信息、资源冲突、修改原因和责任边界变得可见，再由人做最终决定。
The idea began with a recurring contradiction during my Amazon internship: requesters needed a quick commitment, while designers first needed enough information to understand scope and effort. General work-management tools can already collect forms, route tasks and visualize workload; the opportunity here was more specific to design collaboration: translating vague creative language, exposing uncertainty before a deadline is promised, and preserving the reason behind revisions.
一个“下周做一个更年轻、更科技感的首页”看起来只有一句话，却可能同时缺少目标用户、页面范围、品牌规范、确认人和不可变内容。真实沟通往往先谈日期、后补信息，于是设计师实际上同时在补 Brief、估工作量、承担时间承诺。Hackathon 原型因此不从日历开始，而从“承诺成立需要哪些条件”开始。
SOURCE PROTOTYPE / Dashboard, Request Desk, Schedule, Collaboration Memory and Insight are captured from the working prototype source.
四个隐藏成本同时存在：Brief Debt 让设计师替需求方补需求；Capacity Blindness 让插单影响不可见；Decision Ambiguity 让谁确认、谁改优先级变模糊；Revision Amnesia 则只保存“改了什么”，却丢掉“为什么改”。所以问题不是再做一个日历，而是把这些原本散在聊天里的判断变成共享信息。
The two sides are not in conflict because one is unreasonable; they are optimizing for different things.
需求方需要低成本地表达目标、尽快看到状态，不应该先学一套专业 Brief；设计师则必须拿到足够完整、可解释的信息，才能判断工作量和质量风险。因此 AI 的角色不是替任何一方做决定，而是做中间的翻译：自然语言需求 → 已确认/待确认信息 → 风险与冲突解释 → 人的最终承诺。
A language model can make an incomplete request look complete very easily. That is exactly the risk.
所以 Parse Brief 的重点不是“自动补全”，而是把信息明确分成 Confirmed / Inferred / Missing：已经说清楚的直接保留，可以推断但未确认的明确标记，会影响工作量或质量的缺失项转成下一步追问。AI 帮双方更快知道“现在还不能确定什么”，而不是用看起来完整的文本掩盖不确定性。
NATURAL LANGUAGE REQUEST
AI 先保留原始表达，再把确定信息、推断和缺失信息分开。优先级和最终承诺仍由人确认。
STRUCTURED BRIEF
I deliberately avoided turning the system into an automatic priority judge.
拖动紧急度、工作量、需求完整度与当前负载。风险分数只表达“这次承诺建立在多少不确定性上”，并展开可选动作，例如缩小第一版范围、补齐关键输入、调整截止时间或重排现有任务。它不回答“谁更重要”，因为业务优先级、质量标准与最终 Deadline 都属于团队责任。
先补全页面范围和确认人，再在“缩小第一版范围 / 调整截止时间 / 重新排序当前任务”中由团队选择。
Teams usually save the artifact and lose the reason. This prototype treats revision history as decision history.
一个页面从 V1 到 V2，可能因为品牌规范、业务范围、个人偏好或单纯错误修正而变化，这四种原因对下一次需求的意义完全不同。因此这里不只保留版本，还记录修改属于什么类型、为什么接受、会不会影响后续相似任务，让“修改历史”逐渐变成“团队怎样做判断的历史”。
系统不直接覆盖模糊需求，而是保留原文，标记可识别内容和不确定性，为后续确认提供依据。
The most important feature became a boundary: what the AI must never silently decide.
AI 可以整理信息、发现缺失、解释冲突、聚类反馈和维护版本关系，但不能替团队承诺优先级、截止时间、视觉质量和最终责任。这个边界不是项目最后补上的伦理说明，而是产品本身成立的前提：AI structures the negotiation. People own the promise.
STRUCTURE
整理信息、发现缺失、聚类反馈和维护版本关系，可以由 AI 提供辅助。
Parse · Explain · Compare · Remember
Priority · Deadline · Quality · Commitment
PROJECT REFLECTION
The prototype began with scheduling, but ended with a different insight: collaboration breaks when important judgment stays invisible. Instead of recreating the form, calendar and workload functions that general work-management tools already provide, this concept focuses on the design-specific chain before commitment: vague creative language, incomplete evidence, subjective feedback, revision reasons and responsibility.
差异点不在于“AI 会不会排期”，而在于它把承诺之前的条件变成可讨论对象：需求到底确认了多少、资源冲突在哪里、修改为什么发生、谁拥有最终决定。AI 在这里更像结构层、解释层和记忆层，而不是自动经理。
VIEW PROTOTYPE EVIDENCE ↓SYSTEM 03 / AI SKILL & CLIENT WORKTREE
A reusable AI Skill grown from repeated website delivery. The repeated work was not coding; it was judgment: understanding who the person needs to convince, which projects deserve emphasis, what evidence is credible, what visual language fits the content, and what AI must never invent. The worktree externalizes those decisions so AI can execute repeatable structure while human review protects positioning, facts, taste and final quality.
这个项目不是从“一键生成网站”开始，而是从真实网站交付里长出来的。随着资料类型和客户目标变多，我发现真正反复消耗时间的不是 HTML，而是每次都要重新理解一个人、重新做项目取舍、重新判断风格与事实边界。于是我把这些原本隐性的判断拆成 Worktree，让 AI 执行可重复部分，人保留职业定位、内容权重、审美和最终交付判断。
This is a working Skill shaped by heterogeneous paid requests, not a template shelf. Real clients rarely arrive with a clean prompt: they bring CVs, project folders, mixed-quality images, reference sites, vague taste words and different career goals. The system therefore starts before generation: understand the person, decide what the site must prove, build content hierarchy, extract suitable style rules, then code, review and deliver.
小红书与闲鱼的真实咨询让这套方法不断面对不同输入：有人项目很多但重点不清，有人风格偏好明确但目标岗位模糊，有人需要快速上线，有人会多轮修改。商业闭环的意义不是“有流量”，而是持续把新的资料复杂度和真实交付约束送回 Worktree，逼迫方法变得更稳定。
客户往往不是“没有内容”，而是内容太多、关系太散。简历、自述、作品图片、旧网站和参考案例都可以很完整，但如果系统不知道目标岗位、主要受众和需要建立的职业印象，最容易生成的是“什么都放进去了”的网站，而不是“这个人为什么值得被继续了解”的网站。输入完整 ≠ 定位清楚。
小红书、闲鱼等渠道带来的真实需求让我不断重复同一组判断：这个人投什么、首页先证明什么、哪些项目该放大、参考风格到底适不适合他的内容、哪些事实必须再次确认、移动端怎么保证可读。也正因为输入足够不同，我才开始意识到：真正值得自动化的不是“帮我写 HTML”，而是把这些判断步骤变成可检查的流程。
当 Intake、Identity、Content Strategy、Style DNA、Site Map、AI Coding、Human Review 和 Delivery 被拆成明确节点后，Agent 可以承担提取、分类和重复构建，我把时间集中在定位、事实、审美、交互和最终交付。每一轮都有可确认产物，也能在修改时从正确节点继续，而不是整站重新生成。
The eight nodes were not invented to make a neat process diagram. Each one corresponds to something that had failed in earlier delivery: images assigned to the wrong project, beautiful sites that missed the target role, every project receiving equal weight, reference sites copied only at surface level, AI overstating facts, responsive layouts breaking, or later revisions restarting from zero.
所以 Worktree 的优势不是“步骤多”，而是把真实失败提前变成检查点。Agent 能知道自己当前在理解人、排内容、提取 Style DNA、构建页面还是等待人工 QA，也让一次交付积累的规则可以进入下一次，而不是只留下一份最终 HTML。
收集、分类、去重、提示缺失。
理解职业方向、能力与受众。
项目排序、详略与首页叙事。
提取视觉规则而非复制表面。
页面、section 与内容 Schema。
生成骨架、模块与响应式基础。
审美、事实、权重与体验校对。
部署、记录与继续更新。
This is where the Skill deliberately differs from a generic AI website builder: the same source material should not produce the same story.
投 AI 产品、UX、Creative Technology 或研究生申请时，HR / 导师要寻找的证据完全不同。目标改变后，项目排序、首页第一屏、案例详略和证明方式都应重算。用户说“我喜欢这个网站”只是一个偏好输入，真正的内容策略还要同时看目标岗位、受众阅读速度、项目类型、图片质量和需要建立的职业印象。
通用 AI Builder 已经能够根据 Prompt 生成页面，真正困难的不是“像不像参考图”，而是“哪些规则适合这个人”。因此 Agent 不接收“照着这个网站做”作为最终指令，而会先解释参考为什么成立：Hero 是图像优先还是观点优先、标题与正文尺度如何、每屏信息密度、图片比例、页面节奏、导航与动效在承担什么作用，再判断哪些规则适合当前内容。最终保存的是可解释的 Style DNA，而不是待复制的截图。下面的样本只承担规则参考，不冒充客户案例。
The button looks like one click, but the system behind it is a sequence of explicit decisions.
Run Worktree 并不是把设计交给模型，而是连续执行已经定义好的判断：Collect → Extract → Understand → Prioritize → Match → Structure → Code → Review → Deliver。AI 适合承担文件识别、信息提取、初步聚类、重复结构和代码骨架；职业定位、项目取舍、事实与隐私、审美方向、最终体验和“是否可以交付”始终由人负责。自动化放大的是方法，不是随机性。
COLLECT
收集资料
EXTRACT
提取信息
UNDERSTAND
理解定位
STRUCTURE
内容架构
MATCH
风格规则
CODE
生成页面
REVIEW
人工校对
DELIVER
部署归档
Paid delivery became the real stress test of the workflow. Generic AI builders already prove that a site can be generated from a prompt; what I needed to validate was whether a method could repeatedly handle different people, uneven materials, conflicting preferences and real revision requests without losing positioning or factual accuracy.
当前 23 次付费交付的意义不只是商业结果。每一个新客户都在测试 Worktree 的不同假设：项目多但图片弱、目标岗位模糊、参考风格与内容密度冲突、需要快速上线或持续修改。¥10K+ 与 2h → 1–1.5h 说明这套方法开始具备可重复交付价值，而不是只适用于我自己的一个 Demo。下方仍明确展示为 Style Reference Library，不把第三方网站包装成客户作品。
已成交定制项目
累计收益
单个网站平均制作时间
Agent 先分析简历、自我描述、作品、目标岗位、个人偏好和参考网站，再按 Worktree 规则判断项目权重、提取 Style DNA、构建页面 Schema 和代码骨架。真正可复用的资产不是某一份 HTML，而是“这个人需要证明什么、什么内容先出现、哪些风格规则适用、哪些事实不能推断、哪些节点必须人工验收”的判断框架。最终输出仍经过事实、审美、响应式与部署 QA。
Huajian taught me that generation is only one moment inside a longer production workflow. DesignOps taught me that collaboration cannot be improved by hiding uncertainty behind an automatic schedule. Website Skill taught me that automation becomes useful only after editorial and design judgment is explicit enough to execute and review.
三个项目分别处理生产、协作与交付，但真正一致的能力是：从真实工作里发现被忽略的摩擦，把隐性判断拆出来，设计 AI 可以进入的结构，再清楚标出它应该停在哪里。不是“多做三个 AI 功能”，而是让复杂工作更容易被理解、判断、复用和继续。
It relocated human judgment: earlier, clearer and closer to the moments where structure, direction, responsibility and reuse are decided.
重点不是“AI 做出了什么”，而是我如何通过调研、测试和系统设计，让人的判断更早出现、更清晰可见，并能够被团队继续使用。