云景阁

GitHub Agent + OpenSpec SDD 纯 Issue 驱动工作流整合方案

Mon, 02 Mar 2026 00:00:00 +0000

1. 这是什么问题？

我希望探索一种将 GitHub Copilot Coding Agent、OpenSpec SDD（Spec-Driven Development） 和 GitHub Actions CI 整合在一起的工作流，实现：

代码与文档分离（单仓库双目录）
以 Issue 为核心驱动 SDD 全生命周期
新增 Issue 自动触发 CI 生成 SDD 骨架
SDD 完成后可自动分配给 Copilot Agent 实现

核心约束：必须可落地、可执行，零额外依赖。

2. 核心结论 / 判断

纯 Issue 驱动 > Project Board 同步展示。

经过多轮迭代验证，最终方案砍掉了 GitHub Project Board，理由是：

Project Board 在此场景中仅作为”只读镜像”，无决策价值
引入 Project 需要 PAT Token、GraphQL mutation、组织级权限等大量额外依赖
Issue Label 本身就是天然的状态机，完全可以替代 Board 的状态流转

砍掉后，整个方案：

维度	含 Project Board	纯 Issue（最终版）
Secrets	1 PAT + 5 Variables	0（仅 GITHUB_TOKEN）
GraphQL 调用	4 处 mutation	0
落地难度	需 Org Admin 配合	仓库 Maintainer 即可
可移植性	依赖组织级 Project	任何仓库即开即用

3. 设计理念

Issue 是"第一公民"，Label 是"状态机",
Milestone 是"版本线”，PR 是"交付物"。
不需要一个额外的看板来"展示"这些已经存在的东西。

4. 前置条件

#	条件	确认方式
1	Node.js ≥ 20.19.0	`node -v`
2	OpenSpec CLI	`npm install -g @fission-ai/openspec@latest`
3	Copilot Coding Agent 已启用	Repo → Settings → Copilot → Agent ✅
4	Actions 读写权限	Repo → Settings → Actions → General → Read and write ✅

不再需要 PAT Token、PROJECT_TOKEN Secret、任何 Project Variables。所有 Workflow 仅使用自动注入的 GITHUB_TOKEN。

my-project/
├── src/                                # 💻 代码
│   └── ...
├── .openspec/                          # 📄 SDD 文档
│   ├── config.json
│   ├── specs/                          #   源真相 (Source of Truth)
│   │   └── <capability>/spec.md
│   └── changes/                        #   活跃变更
│       └── <change-id>/
│           ├── proposal.md
│           ├── tasks.md
│           ├── design.md              (可选)
│           └── specs/<domain>/spec.md
├── .github/
│   ├── workflows/
│   │   ├── 01-sdd-init.yml
│   │   ├── 02-sdd-validate.yml
│   │   ├── 03-sdd-implement.yml
│   │   └── 04-sdd-archive.yml
│   ├── ISSUE_TEMPLATE/
│   │   └── sdd-request.yml
│   └── copilot-instructions.md
└── README.md

关键区分：

src/ — 纯代码，Copilot Agent 的工作区域
.openspec/ — 纯文档，SDD Pipeline 的工作区域
.github/ — 自动化胶水层

6. Label 状态机（替代 Project Board）

Issue 生命周期：

[sdd] ─── Workflow 01 ───▶ [sdd:spec-ing]
                                 │
                           团队完善 SDD
                           Review & Merge PR
                                 │
                                 ▼
                          [sdd:spec-ready]
                                 │
                           Workflow 03
                           创建实现 Issue
                                 ▼
                       [sdd:implementing]
                       + [copilot-assigned]
                                 │
                          Copilot / 人工
                          提交 & 合并实现 PR
                                 ▼
                           [sdd:done]
                           Issue 自动关闭

所需 Labels：

Label	颜色	说明
`sdd`	`#7057ff`	SDD 流程入口
`sdd:spec-ing`	`#fbca04`	SDD 文档编写中
`sdd:spec-ready`	`#0e8a16`	SDD 文档已就绪
`sdd:implementing`	`#1d76db`	代码实现中
`sdd:done`	`#0e8a16`	已完成并归档
`copilot-assigned`	`#8b5cf6`	已分配给 Copilot Agent
`auto-implement`	`#d93f0b`	SDD 合并后自动交给 Copilot

日常查询：

所有 SDD 进行中:    is:open label:sdd:spec-ing
等待实现:           is:open label:sdd:spec-ready
实现中:             is:open label:sdd:implementing
Copilot 处理中:     is:open label:copilot-assigned
已完成:             label:sdd:done is:closed

7. 两套命令体系（避免混淆）

Shell CLI（CI/CD 中使用）	AI IDE 内 OPSX 指令（开发者在 IDE 中使用）
`openspec init`	`/opsx:new <change>`
`openspec validate`	`/opsx:ff`
`openspec archive`	`/opsx:continue`
`openspec --version`	`/opsx:apply <change>`
	`/opsx:verify <change>`
	`/opsx:archive <change>`

⚠️ CI/CD 工作流中只能使用 Shell CLI，不能使用 /opsx: 指令。OPSX 指令是 AI 编码助手（Claude/Cursor/Windsurf）中的交互式命令。

8. 四个核心 Workflow

8.1 Workflow 01：Issue[sdd] → 生成 SDD 骨架 → 创建 Draft PR

触发条件： Issue 被创建或被打上 sdd 标签

执行逻辑：

解析 Issue 模板中的 Change Name、Summary、验收标准
幂等性检查（分支是否已存在）
在 .openspec/changes/<change-id>/ 生成 proposal.md、tasks.md、specs/
创建 sdd/<change-id> 分支，提交并推送
创建 Draft PR
Issue 标签从 sdd → sdd:spec-ing
在 Issue 中评论 SDD Pipeline 状态

name: "01 📐 SDD Init"

on:
  issues:
    types: [opened, labeled]

permissions:
  contents: write
  issues: write
  pull-requests: write

8.2 Workflow 02：SDD 文件变更 → 自动校验

触发条件： PR 中有 .openspec/** 文件变更

执行逻辑：

检查每个 change 目录的文件完整性（proposal.md、tasks.md、specs/）
检查内容非空（proposal 至少 5 行，tasks 至少 2 个任务项）
运行 openspec validate --all（如果已初始化）
在 PR 中评论校验报告
有缺失必需文件时 CI 失败

name: "02 ✅ SDD Validate"

on:
  pull_request:
    paths:
      - '.openspec/**'

permissions:
  contents: read
  pull-requests: write

8.3 Workflow 03：SDD PR 合并 → 创建实现 Issue → 可选分配 Copilot

触发条件： sdd/* 分支的 PR 被合并到 main

执行逻辑：

从分支名提取 change-id
读取 tasks.md 和 proposal.md 内容
检查原始 SDD Issue 是否有 auto-implement 标签
创建实现 Issue，body 中包含完整的 SDD 上下文
如果 auto-implement，assignees: ['copilot'] → 触发 Coding Agent
SDD Issue 标签 → sdd:spec-ready
在 SDD Issue 中评论链接

name: "03 🤖 SDD Merged → Implement"

on:
  pull_request:
    types: [closed]
    branches: [main]

permissions:
  contents: read
  issues: write

关于 Copilot Agent 触发方式： 通过 REST API 将 Issue 的 assignee 设为 "copilot" 即可触发。Agent 会自动分析仓库、读取 SDD 文件、创建分支、编写代码、运行测试，最终提交一个 Draft PR。迭代反馈发生在 PR 评论中，而非 Issue 评论中。

8.4 Workflow 04：实现 PR 合并 → 归档 SDD → 关闭 Issue

触发条件： copilot/* 分支或带 sdd:implementing 标签的 PR 被合并

执行逻辑：

从 PR body 中提取 change-id
运行 openspec archive <change-id> --yes（CLI 失败时手动回退）
合并 delta specs 到 .openspec/specs/
提交归档（commit message 含 [skip ci] 防止循环）
所有关联 Issue 标签 → sdd:done，自动关闭
评论归档完成

name: "04 📦 Impl Merged → Archive"

on:
  pull_request:
    types: [closed]
    branches: [main]

permissions:
  contents: write
  issues: write

9. 完整生命周期时序

👤 PM/Dev                  GitHub Actions                🤖 Copilot Agent
────────                   ──────────────                ────────────────

1. New Issue [SDD]
   label: sdd
   │── issues.opened ─────▶│
                            │ 01-sdd-init
                            ├ 幂等检查
                            ├ 生成 SDD 骨架
                            ├ 创建 sdd/ 分支
                            ├ 创建 Draft PR #2
                            ├ label → sdd:spec-ing
                            └ 评论 Issue #1
   ◀── 通知 ───────────────│

2. 完善 SDD (PR #2)
   │── push ───────────────▶│
                            │ 02-sdd-validate
                            ├ 文件检查
                            ├ openspec validate
                            └ 发布报告
   ◀── 报告 ───────────────│

3. Merge SDD PR #2
   │── merge ──────────────▶│
                            │ 03-sdd-implement
                            ├ 解析 tasks.md
                            ├ 创建 Issue #3
                            │  assignees: [copilot]
                            ├ label #1 → sdd:spec-ready
                            └ 评论 #1
                            │
                            │── Issue #3 ──────────────▶│
                                                        │ 分析仓库
                                                        │ 读取 SDD
                                                        │ 创建分支
                                                        │ 编写代码
                                                        │ 运行测试
                            │◀── Draft PR #4 ──────────│

4. Review & Merge PR #4
   │── merge ──────────────▶│
                            │ 04-sdd-archive
                            ├ openspec archive
                            ├ 合并 delta specs
                            ├ commit [skip ci]
                            ├ label → sdd:done
                            ├ 关闭 Issue #1 & #3
                            └ 评论: archived
   ◀── done ───────────────│

10. 关键设计决策与 Review 记录

10.1 为什么砍掉 Project Board？

问题	详情
`projects_v2_item` 仅组织级	webhook 仅在组织级别生效，repo 级别不收该事件
Actions 触发不稳定	社区广泛报告延迟、丢失事件等问题
权限要求高	需要 Organization Admin + PAT (project scope)
只读镜像无价值	Board 仅同步展示已有 Issue 状态，不产生新决策

10.2 OpenSpec 命令纠错

错误	正确
`npm install -g openspec`	`npm install -g @fission-ai/openspec@latest`
目录 `openspec/`	目录 `.openspec/`（CLI 默认）
`/opsx:` 在 CI 中使用	`/opsx:` 仅在 AI IDE 中使用

10.3 Copilot Agent 触发方式

通过 REST API assignees: ['copilot'] 触发
Agent 自动创建 Draft PR，不在 Issue 中回复
迭代反馈发生在 PR 评论中
需要 Copilot Pro+/Business/Enterprise 订阅
仓库 Settings → Copilot → Coding Agent 需提前启用

10.4 幂等性与健壮性

每个 Workflow 都有幂等性检查（分支已存在则 skip）
openspec archive CLI 失败时有手动回退方案
归档提交使用 [skip ci] 防止无限循环
Label 操作 removeLabel 使用 .catch(() => {}) 容错

11. 已知限制

#	限制	应对策略
1	`assignees: ['copilot']` 要求 Agent 已启用	Workflow 中 `continue-on-error` + 回退为手动
2	OpenSpec CLI 仍在快速迭代	archive 步骤有手动回退方案
3	`[skip ci]` 提交不触发后续 workflow	这是期望行为，防止循环
4	Copilot Agent 只适合中小型任务	大型任务手动实现，不打 auto-implement
5	branch protection 可能阻止 bot push	需配置允许 `github-actions[bot]`

12. 日常使用速查

你想做什么	操作
发起新需求	New Issue → 选 “SDD Request” 模板 → 自动触发
查看 SDD 进行中	`is:open label:sdd:spec-ing`
查看等待实现	`is:open label:sdd:spec-ready`
查看实现中	`is:open label:sdd:implementing`
查看 Copilot 处理中	`is:open label:copilot-assigned`
查看已完成	`label:sdd:done is:closed`
本地编辑 SDD	`git checkout sdd/<change-id>` → 编辑 → push
IDE 中用 OPSX	`/opsx:new <id>` → `/opsx:ff` → `/opsx:apply`

13. 总结

这个方案的核心是：

Issue 是入口，Label 是状态机，SDD 是规格标准，Actions 是自动化引擎，Copilot Agent 是可选执行者。

它不依赖任何额外的 Token、Project Board 或组织级权限。Clone 仓库 → 跑初始化脚本 → 提 Issue → 自动运转。

这不是一个理论方案，而是一个可以直接 copy-paste 到任何 GitHub 仓库中立即使用的工程实现。

参考链接

使用 GitHub Pages + Copilot Agent 构建个人知识库的可行性分析

Wed, 11 Feb 2026 00:00:00 +0000

1. 这是什么问题？

我希望探索一种长期可维护、可演化的方式，用于记录个人思考，并借助 GitHub Copilot / Agent 能力，对这些知识进行新增与检索。

核心设想是：

使用 github.io（GitHub Pages）作为知识的最终载体
使用 Git 仓库作为思想的版本化存储
使用 Copilot + Agent Skill 辅助完成：
- 新增结构化文档
- 从已有知识中检索与总结特定问题

问题在于：
这个方案是否真的可行？边界在哪里？会踩哪些坑？

2. 核心结论 / 判断

这个方案在工程层面是可行的，在方法论层面是“有条件成立”的。

它非常适合用来构建一个：

面向长期的
可追溯演进的
以“已成型思考”为主的

个人知识库（而非灵感捕捉系统或第二大脑）。

GitHub Pages 负责“稳定呈现”，
Copilot / Agent 负责“结构化整理与辅助回忆”，
判断与洞察仍然必须由人来完成。

3. 推理与依据

3.1 GitHub Pages 作为知识载体的优势

全部内容为纯文本（Markdown）
可版本控制、可 diff、可回滚
不依赖第三方 SaaS 的生命周期
思考过程本身可被保留（commit history）

这使它非常适合作为长期思想资产，而不是短期笔记。

3.2 Copilot / Agent 的真实能力定位

Copilot 并不真正“理解你”，但它非常擅长：

将非结构化输入整理成结构化文档
按固定模板重写、补全、规范表达
在给定上下文中，对已有内容进行总结与对比

因此，它更像是一个：

高级编辑器 + 结构化助理
而不是“自动产生新知识的智能体”。

3.3 文件系统 vs 人类认知的天然冲突

GitHub 的底层模型是：


目录 / 文件 / 行

而人的认知模型是：


概念 / 关联 / 权重 / 上下文

这意味着：

知识之间的“关系”无法自动维护
Copilot 无法天然知道哪些概念在体系中是核心
写得越多，整体理解成本越高

这构成了该方案的结构性上限。

4. Agent Skill 的设计思路

为了避免“AI 注水型知识库”，需要对 Agent 进行强约束设计。

4.1 Agent Skill：KB-Writer（新增文档）

目标
将零散想法转化为一个“可长期维护的知识节点”。

关键原则

不允许引入用户未表达的新观点
强制输出结构化 Markdown
明确结论、推理与适用边界
信息不足时必须显式标注“不确定”

本质角色
👉 一个“严谨的整理员”，而不是作者。

4.2 Agent Skill：KB-Query（知识检索）

目标
在已有文档中，对某个问题进行一次可解释的回忆与总结。

输出必须包含

明确结论
引用的具体文档
不一致或冲突点
适用前提与置信度说明

能力边界

无法保证全库无遗漏
无法替代人工判断
不应被当作搜索引擎或裁决者

5. 主要痛点与缺陷

5.1 查询能力有限

缺乏真正的语义索引
跨主题检索容易遗漏
Copilot 无法给出“结果完整性”的保证

5.2 写入摩擦随时间上升

目录与标签需要持续维护
文档重构成本逐年增加
容易在 6–12 个月后陷入结构债务

5.3 Agent 不具备长期记忆

每次理解都是“临时上下文”
无法真正形成对个人知识体系的内化理解

6. 适用边界

6.1 这个方案适合

成熟后的思考沉淀
方法论、系统设计、模型分析
希望公开、可检验的思想资产

6.2 这个方案不适合

随手灵感记录
高度碎片化的信息流
期待 AI 自动产生洞察或决策

7. 实践建议（避免一年后崩盘）

设置“缓冲区”（草稿 / issue / discussion）
只有在想法稳定后才进入 github.io
Copilot 主要参与“整理阶段”，而非“思考阶段”
把“发布”当作一次思考的完成标志

8. 总结

这个方案不是为了追求效率最大化，而是为了：

构建一个不会随工具消失的、可演化的思想结构。

GitHub Pages 是地基，
Copilot 是工具，
而体系是否成立，最终取决于人是否保持判断力与自律。

Unity游戏开发问题排查思路

Mon, 07 Dec 2020 00:00:00 +0000

服务器
- 磁盘
  - 利用 df -h 获取磁盘空间状态
  - 利用 ls -lh 查看文件大小
  - 利用 du -h 查看文本夹大小
- CPU
  - 利用top查看进程状态
    - 获取CPU/内存使用率最高的进程pid、启动命令等信息
  - 利用 top -H 查看线程状态
    - 获取CPU/内存使用率最高的线程信息
- 内存
  - 利用 free -h 查看内存使用情况
数据库
- 慢SQL
  - 利用explain执行计划优化SQL
    - 利用索引提速
    - 小表驱动大表
  - 利用 show processlist 然后kill终结慢查询
- 连接过多
  - 利用 set global max_connections增大连接数
  - 利用 show processlist 然后kill终结多余的连接
- 死锁
  - 事务隔离级别
  - 锁时序分析
    - 表锁
    - 页锁
    - 行锁
      - Record Lock
      - Gap Lock
      - Next-Key Lock
    - 意向锁
Redis
- 内存不足
  - 大key
    - rdbtools查询大key
    - 利用redis-cli查询大key
    - 利用debug object key查看key序列化后的大小
  - config set maxmemory临时增加内存
  - 指定内存淘汰机制
- 连接数过多
  - config set maxclient临时增加最大连接数
  - 限制客户端最大连接数
- 慢命令
  - config set slowlog-log-lower-than设置慢命令阙值
  - config set slowlog-max-len设置最大慢命令记录保存数
  - 利用slowlog get查询慢命令
- 查询网络延迟
  - redis-cli -latency查询延迟信息
网络
- 利用 netstat 查询统计网络状态
业务线

记录在Unity的使用过程中，可能遇到的问题

Sat, 18 Jul 2020 00:00:00 +0000

概述

以此文来记录平时学习使用Unity过程中碰到的问题，加强记忆避免再次发生。

大部分问答来源于网上，本文只是记录与自己相关的，并根据Unity的最新LTS版本进行答案更新。

一、AssetBundle相关

Q1: 请问内置的shader怎么打包？我用到了内置材质球，不只是Shader，这时候在Profiler中看到加载的结果会出现多份。

通常有两种方式对内置的Shader进行打包：

将其添加到Graphics Settings中的Always Included Shaders中，此时添加后的内置Shader就不会被打入AssetBundle包中；

在Unity官方资源上下载内置的Shader，将其导入项目，并替换成非内置的材质球，从而可以直接通过脚本来控制其打包的方式。

Q2：项目在发布时，Player Setting中勾选的这个选项(Optimize Mesh Data)，对于已经打包并且放到了Streaming Assets中的AssetBundle文件有效果吗？模型资源里有个Optimize Mesh，是否能达到同样的效果？

理论上 Optimize Mesh Data 是 Build Player 或者 Bundle 时才生效的，所以之前打好的 Bundle 就没效果了。另外，两个选项的效果是不同的，后者是调整面片排序的。

二、资源使用

纹理相关

Q1、同样的包同一个图集，ETC2格式，在红米Note1上会比酷派的内存会大四倍，请问这是什么原因造成的？如果不支持OpenGL 3.0，会造成这么大的影响吗？

ETC2 的格式理论上只在OpenGL ES 3.0 的设备上被支持，而在不被支持的设备上则会内部自动转成 RGBA32/ARGB32的格式，这对于 RGBA Compressed ETC2 8bits 的纹理就是放大了 4 倍。因此，如果希望在 OpenGL ES 2.0 的设备上对透明材质进行压缩，那么可以尝试使用分离 Alpha 通道的方式，用两个 ETC1 来进行压缩。

Q2、iOS平台需要对图集做RGB和Alpha通道的分离吗？我发现在同样大小的图片（正方形），RGB Compressed PVRTC 4bits和RGBA Compressed PVRTC 4bits两种格式，占用内存是一样的，如果把一张图片分成两张，那么在iOS平台是不是占用内存多一倍？有透明通道的，对于它的图集怎么处理会更好一点？

通常iOS下是不需要做通道分离的，因为 iOS 通用的 PVRTC 格式支持 Alpha 通道。但目前也有团队反馈，在 iOS 上进行通道分离有助于减少失真，可以在一定程度上提高视觉效果，因此也可以尝试做一个对比。如果发现占用内存是一样的，那么原始图片是RGB的。如果iOS上做通道分离，内存确实会增加一倍。UI的纹理在iOS下可以直接选择默认的 Compress，在打Atlas时会自动处理成 PVRTC，开发团队可以从Sprite packer窗口来看Atlas的压缩格式做个确认。

Q3、请问Unity引擎中使用什么贴图压缩格式，可以保证在占用内存相对较小的情况下True Color效果和原图相当？同时在iOS和Android平台上图片的压缩格式分别用什么比较合适？有什么需要注意的地方吗?

目前来讲，并不存在一个所有GPU平台都支持硬件解压的压缩格式。 ETC1 和 PVRTC 分别是Android和iOS上我们最推荐的格式。但对于透明纹理，ETC1不支持，而 PVRTC 则可能有较大失真，因此更推荐使用 RGBA 16。一般来说建议直接使用 Unity 默认的压缩格式（即选择 Compressed 即可，不需要做特殊设置），Unity 会做如下处理：

Android 上不带Alpha通道的图片采用 ETC1，带Alpha通道的图片采用True Color中的RGB16，TrueColor中的 RGBA16 会>比 RGBA32 更节省空间，但图像的显示质量会差一些；

iOS 上使用 PVRTC，但PVRTC格式要求纹理的长宽相等，且都是2的幂次（即POT，在ImportSettings中可以将NPOT的纹理自动转换成POT）。另外，针对Android 上的带Alpha通道的图片，还有一种常见的做法，即把Alpha通道独立出来作为另一张纹理，从而将 RGB 部分和 Alpha 部分分别采用 ETC1来压缩，但渲染时就需要自定义的 Shader来处理。同时，我们不建议直接使用 RGBA32 格式的纹理，因为它占用了很大的内存。一般建议使用 RGBA16 和 ETC 格式的纹理来进行加载。如果转换到 RGBA16 格式时出现了类似“色阶”的颜色问题，则建议尽可能避免大量的过渡色使用。

网格相关

Q1、我有一个特效依赖了两个FBX。我把这两个FBX的这个勾选去掉，Editor运行正常。否则就会宕机，请问这是什么原因？

将FBX上的Read/Write Enabled关闭后，内存中便不再保存其Mesh的副本（只存在显存中），因此其属性就不可再被访问和修改。而粒子系统通常需要动态地修改其粒子的顶点属性。因此，理论上来说，供粒子系统使用的Mesh是需要开启Read/Write Enabled的，而在Editor下Mesh和Texture都是强制开启的，所以在真机上就会出现问题。

动画片段相关

音频相关

Q1、请问音频中的 Quality 什么意思？一般设置为多少合适？我拖进去一首歌曲，试了一下在0 和 100 的情况下区别不大，但是生成的音频文件大小差别很大。

Quality 表示在压缩音频时的失真程度（实际上可以认为是压缩算法的一个参数），该值越大，压缩后的文件越大，但音质保留的越好。而对于其失真的程度是视音频数据以及内部的压缩算法而定的，确实会有区别不大的情况。该值的设置原则就是，在音质失真可接受的情况下，越小越好。

材质相关

Shader相关

Q1、以前端游时代，材质根据Pass不同、光照环境不同可以离线预编译成ShaderCache，运行时并不需要拼材质再实时编译，只要加载二进制代码就好了。那Unity有没有做这件事呢？我们是根据平台和环境预编译的Shader。

对于支持 Binary Shader 加载的设备，在首次编译某个 Shader 的时候是会生成其对应的 Binary Shader Cache ，生成的 Binary 文件位于和 Application.persistantPath 并列的Cache 目录下。

Q2、相同效果前提下，就性能而言，Shader 是用 V&F 还是Surface好？

Surface生成的V&F比较庞杂，分支较多，如果不注意 #pragma surface 参数的选择，容易出现不必要的开销。举例来说，如果直接用 Unity 5.x 中默认创建的 Surface Shader （默认参数为 #pragma surface surf Standard fullforwardshadows），那么 Shader 是会做 Physically based Standard Lighting 的，而这在移动端开销非常大，且并非必要。

字体相关

Q1、我们现在为了美观，需要同时使用2套字体。但是每增加一套字体，就会内存增加50MB左右。请问你们在优化其他Unity游戏时，怎么处理类似情况的？

如果美术字不多的话，建议使用单独的字体贴图来进行实现，从而来达到特定美术字显示的效果；如果美术字较多的话，那么仅能建议使用另外一个套字体来进行实现。一般来说，字体的内存量应该也是完全可以控制在10MB以下的。

粒子系统

Lightmap

Q1、Lightmap在PC上显示正常，但是转到Android平台上存在色差，颜色普遍偏暗。

一般来讲，有两种情况可能会导致色偏和亮度差异。

Unity烘焙的Lightmap是32bit的HDR图，而移动设备通常不支持HDR图(32bit per channel)，会按照LDR图(8bit per channel)的形式进行处理，因此会出现色偏问题。因此我们建议：

在移动平台下使用Mobile/Diffuse材质，可载入Standard Assets(Mobile) package获得。如果要获得更合适的效果，需要自行修改Lightmap的DecodeLightmap函数，该函数可在Unity\Editor\Data\CGIncludes\UnityCG.cginc文件中找到。需要说明的是，这种方法也不能达到与PC端完全一致的效果。

如果需要PC和移动平台的显示效果一致，可以用图像编辑软体修改Lightmap為LDR格式，例如PNG(8bit per channel)。

为了避免类似问题，请不要使用过于强烈的Light进行烘焙，因為Light的强度(Intensity)越高，色偏问题会越严重。若有阴影丢失时，可以尝试检查一下模型的Lightmapindex、Lightmapscaleoffset、UV2等影响Lightmap采样的一些参数。

另一种可能是存在过曝现象，可以尝试将playersettings -> use direct3d 11关闭，看问题是否解决。

分布式实时监控系统（不断更新）

Wed, 23 May 2018 00:00:00 +0000

在2010年, Google发表了一篇名为”Dapper, a Large-Scale Distributed Systems Tracing Infrastructure”的论文，在论文中介绍了Google在生产环境中大规模分布式系统下的跟踪系统Dapper的设计和使用经验。实时监控告警和应用性能分析诊断平台，主要包括应用端监控和移动端监控等。

为什么需要跟踪系统

故障快速定位

快速的故障定位非常重要，一个良好设计的系统需要提供快速检测、隔离及修复问题的机制，而快速定位则是这个机制中的重要一环，由于缺乏快速定位的机制，当关键业务出现服务停止或者性能恶化，对业务有直接影响时，由于缺乏有效和快速的应对措施，往往由最终用户的反馈作为整个定位的开始一环，而此时已经是损失很难挽回的时间点了。

恶性循环的形成

由于缺乏快速定位机制，那些长期存在的性能低下问题以及重复出现的问题很难精确定位，产生了大量的技术债务。而随着新的功能的不断添加，同样无法尽早或者预先发现问题导致问题也不断的累积。修改自身也可能会导致更多问题的引入，从而形成了恶性循环。

现状把握&决策支持

根据跟踪系统提供的数据可以提供及时和全面的性能报告，并且在此基础之上，能够做进一步的分析从而提供决策支持的所需数据，比如根据收集的信息可以对用户行为/模式分析：从而进一步地进行测量和管控。

启示1：跟踪系统的两个重要需求

在Dapper的论文这样认为，有两个重要的需求需要予以满足：ubiquitous deployment和continuous monitoring。而这两个需求分别是对跟踪系统的作用范围（无死角跟踪）和运行方式（24小时不间断）做出了规范。

启示2：跟踪系统的三大设计要点

低损耗（Low overhead）

跟踪系统的接入不应该产生很高的性能损耗。具体要求多低，Dapper论文中使用的是negligible(微不足道的，可以忽略的), 如果从度量的角度来讲，pinpoint的实现是3%一下。

应用级透明（Application-level transparency）

由于业务逻辑的不断增长，如果跟踪系统在设计上无法做到对于应用程序的较小侵入性，会导致大量的维护成本以及引入额外缺陷的机率大大提高。理想的做法是能达到论文中所提到的那样：程序员应该不需要意识到有追踪系统的存在。而在实际的实践中，比如引入zipkin或者pinpoint，或多或少还是需要一定的成本，至少跟踪系统的埋点不与业务逻辑产生紧密耦合还是可以实现的，但是完全无意识追踪系统的存在，在具体的实现上还是需要结合系统特点，不是一蹴而就的目标。

扩展性（Scalability）

至少跟踪系统应该要能适应未来几年的服务和集群的扩展。

启示3：跟踪系统的KPI

采样率：根据Google的实践经验，采样率效率1/16时便能避免明显延迟，性能损耗在实验误差范围之内。跟踪大量服务时，采样率调整到1/1024就有足够的跟踪数据，同时能保证性能损耗非常低。Dapper的第一个生产版本对所有进程采用1/1024的统一采样率，后来演进为可变采样率。
损耗：跟踪系统自身的性能影响对于系统应该是能够忽略不计的，pinpoint控制在3%之内。
实效性：跟踪数据产生之后，分析的速度需要及时快速，理想状况数据在一分钟之内能够统计出来，以便对于生产环境的异常状况作出快速反应。

启示5：准确定位延迟问题

当一个系统涉及到多个子系统和多个开发团队的情况下，端到端的性能问题的根本原因定位可以通过跟踪系统来进行。Google通过使用Dapper描述了这种情况下的必需数据，其实践有如下经验：

问题往往来源于一些意想不到的服务之间的交互，问题的纠正往往比较容易，而在Dapper引入之前发现较为困难
简化跟踪的接口，使用唯一的追踪ID，便于集成和检测

启示8：Dapper系统的核心构成

Dapper是通过trace tree和span构建跟踪系统的。

span

span是用用于记录一个服务调用的过程的结构，一个典型的跟踪系统中，一次RPC调用会对应到一个的span上，dapper中定义了span相关的如下信息：

span名称：用于记录span的名称
spanid：用于记录span的Id，一般用全局唯一的64位整数表示
父spanid：父span的spanid，用于描述跟踪树结构
事件信息：cs/cr/sr/ss四种事件类型，span不同的事件类型对应不同的时间戳，根据这些时间戳，可计算出不同阶段的耗时信息。
annotation：一般，事件信息在annotation中存放，另外自定义的信息也可以与之关联

缩写	全称	说明
cs	client send	客户端/消费者发起请求
cr	client receive	客户端/消费者接收到应答
sr	server receive	服务端/生产者接收到请求
ss	server send	服务端/生产者发送应答

trace tree

一个请求可能跟多个服务调用关联，每次服务的调用与一个span进行关联，而span之间通过父spanid进行连接，这样所组成的一个树形结构就是所谓的跟踪树，这个结构显示体现了某一请求的服务调用链的状况。比如论文中的例子即为一个典型的三层架构的例子：具体说明如下：

层次	服务名称	父span	调用顺序
前端	Frontend：A	无	1
中间	MiddleTier：B	A	2
中间	MiddleTier：C	A	3
后端	Backend：D	C	4
后端	Backend：E	C	5

这样的一个树形结构，表现出来的调用顺序则是：A->B->C->D->E。这样的一个简洁的设计，就是dapper的主要构成，可以看出其与业务逻辑基本不相关的一个通用的模型，而在zipkin等的实现中，可以清晰地看到Dapper的整体设计思路。

启示9：定位全局网络流量和使用率

Dapper不是设计用来做链路级的监控的，但是在实践中发现，其比较适合去做集群之间活动性的应用及行为分析，显示集群之间最活跃的网络流量的应用级热点，与传统的网络相关的工具相比，最重要的特点是Dapper可以定位到应用程序级别的根本问题。

启示10：Dapper不太适合的场景

Dapper的模型的隐含前提是不同的子系统使用同一个被跟踪的请求所产生的连锁链式调用栈的情况。如果是多个追踪请求合并起来，而最终只使用其中的一个的情况则无法很好地对应。 Dapper可以找出性能瓶颈，但是并不一定能准确定位到根本原因，因为定位出很慢的结果往往是由其他请求造成的，而这则需要进一步的分析。 Dapper的设计主要是针对在线服务的系统，尤其是一个用户请求的系统行为，但是离线的情况下，则不能直接使用，需要一些人工的关联和干预行为。

Dapper的实现

名称	开发商	类型	源码地址
zipkin	twitter	开源	https://github.com/openzipkin/zipkin
pinpoint	naver	开源	https://github.com/naver/pinpoint
appdash	sourcegraph	开源	https://github.com/sourcegraph/appdash
cat	大众点评	开源	https://github.com/dianping/cat
hydra	京东	开源	https://github.com/odenny/hydra
鹰眼	阿里巴巴	闭源	-

大众点评的cat实现参考

客户端SDK设计

用途	示例	对应接口
一段代码执行时间	url/sql响应时间	Transaction
一段代码执行次数	Exception出现次数	Event
定时执行某些代码	分钟粒度CPU,IO	HeartBeat
一个指标的变化值	监控销售额	Metric

消息生命周期

构建、传输、分析、存储、展示

参考链接

Dapper, a Large-Scale Distributed Systems Tracing Infrastructure
开源分布式监控 CAT 系统的高可用实践
 大规模分布式系统的跟踪系统：Dapper设计给我们的启示
 全链路监控（一）：方案概述与比较

理解架构之路（不断更新）

Sat, 28 Apr 2018 00:00:00 +0000

软件架构的重要性

软件架构能够满足系统的品质
架构设计使受益人达成一致的目标
架构设计能够支持计划编制过程
架构设计对系统开发的指导性
架构设计能够有效地管理复杂性
架构设计为复用奠定了基础
架构设计能够降低维护费用
架构设计能够支持冲突分析

配置中心的设计与选型（未完成）

Fri, 23 Feb 2018 00:00:00 +0000

此文未完结，待补充完善

服务治理

配置中心的配置管理和动态配置下发能力，使得它可以承担服务治理中的Control Plane的职责，它可以把服务治理相关的配置下发给实际的执行模块，比如Dubbo，或者是Spring Cloud集成的Netflix治理工具库，比如Hystrix以及Ribbon。

服务治理的主要功能包括：

注册/发现，服务实例启动后，将会自动通过Hawk Client向配置中心注册，运维可以在配置中心门户查看服务的实例列表，并进行实例级别的服务治理。
负载均衡，调用其他服务时，可以灵活指定其负载均衡策略，如 round robin、hash、consistent hash、weight based round robin等等。
路由，配置微服务的路由策略和路由规则，路由策略如本地优先，本地数据中心优先等等，路由规则如白名单，黑名单，流量引导，读写分离，前后端分离，灰度升级等等。
限流，针对某个调用方限流对象进行QPS限流，分钟级或秒级，或针对所有微服务客户端进行限流。
降级，针对某个降级对象，进行手动或者自动降级（容错），并制定降级策略，抛出异常或特定返回值。
容错，针对某个微服务，设定调用超时与重试策略。
熔断，针对某个微服务或者RPC方法，设定熔断的触发条件，可以强制熔断，或者自动熔断，也可以取消熔断，运维可以指定熔断参数，比如异常，错误码，失败次数比率，时间窗口，以及窗口请求书等等。

参考资料

分布式配置中心架构与实战

网络通信协议的设计杂谈

Thu, 08 Feb 2018 00:00:00 +0000

当设计网络通信协议时，有许许多多的情况和问题需要考虑。

是广播还是单播？
消息应该是有状态还是无状态？
协议是可靠服务还是不可靠服务？
是否需要响应？
您想要使用什么数据格式？
消息流是使用突发性的还是稳定性的？
Ethernet和Internet最好使用突发性消息流。
有多流同步的需求？
建立的是单独的应用还是需要给他人使用的库？

微服务架构杂谈

Thu, 08 Feb 2018 00:00:00 +0000

微服务架构需要关注的技术点

基础设施自动化
服务注册与服务发现
服务路由
服务熔断
集中配置
统一日志收集
服务监控

至少应包含以下功能

服务注册与服务发现
负载均衡
消息总线，轻量级的MQ或HTTP
日志审计，主要是日志的汇总、分类和查询
监控和告警，主要是监控每个服务的状态，必要时生产告警
部署和升级
事件调度机制
资源管理，如底层的虚拟机、物理机和网络管理

另外一些可选的功能

微服务统一代码框架，支持多种编程语言
统一服务构建和打包
统一服务测试
微服务CI/CD流水线
服务依赖关系管理
统一问题追踪调试框架（调用链）
灰度分布
蓝绿部署

刁钻而无意义的笔试题

Tue, 09 Jan 2018 00:00:00 +0000

今天在网上看到有人发表了一篇关于一个无意义而刁钻的笔试题，如

#include <stdio>

int main( )
{
    http://www.yunjing.me
    printf("http://www.yunjing.me\n");
    return 0;
}

让分析这段代码是否存在问题，若有则指出问题所在。

知道猫腻后，就打算用Go语文来装一下，然后，结果很神奇。

package main

func main() {
    http://www.yunjing.me
    println("http://www.yunjing.me")
}

惊叹于Go语言的极简设计理念，这类刁钻的笔试题并无用武之地，Go编译时报错: label http defined and not used

云景阁

GitHub Agent + OpenSpec SDD 纯 Issue 驱动工作流整合方案

1. 这是什么问题？

2. 核心结论 / 判断

3. 设计理念

4. 前置条件

5. 仓库目录结构（单仓库双目录）

6. Label 状态机（替代 Project Board）

7. 两套命令体系（避免混淆）

8. 四个核心 Workflow

8.1 Workflow 01：Issue[sdd] → 生成 SDD 骨架 → 创建 Draft PR

8.2 Workflow 02：SDD 文件变更 → 自动校验

8.3 Workflow 03：SDD PR 合并 → 创建实现 Issue → 可选分配 Copilot

8.4 Workflow 04：实现 PR 合并 → 归档 SDD → 关闭 Issue

9. 完整生命周期时序

10. 关键设计决策与 Review 记录

10.1 为什么砍掉 Project Board？

10.2 OpenSpec 命令纠错

10.3 Copilot Agent 触发方式

10.4 幂等性与健壮性

11. 已知限制

12. 日常使用速查

13. 总结

参考链接

使用 GitHub Pages + Copilot Agent 构建个人知识库的可行性分析

1. 这是什么问题？

2. 核心结论 / 判断

3. 推理与依据

3.1 GitHub Pages 作为知识载体的优势

3.2 Copilot / Agent 的真实能力定位

3.3 文件系统 vs 人类认知的天然冲突

4. Agent Skill 的设计思路

4.1 Agent Skill：KB-Writer（新增文档）

4.2 Agent Skill：KB-Query（知识检索）

5. 主要痛点与缺陷

5.1 查询能力有限

5.2 写入摩擦随时间上升

5.3 Agent 不具备长期记忆

6. 适用边界

6.1 这个方案适合

6.2 这个方案不适合

7. 实践建议（避免一年后崩盘）

8. 总结

Unity游戏开发问题排查思路

记录在Unity的使用过程中，可能遇到的问题

概述

一、AssetBundle相关

Q1: 请问内置的shader怎么打包？我用到了内置材质球，不只是Shader，这时候在Profiler中看到加载的结果会出现多份。

Q2：项目在发布时，Player Setting中勾选的这个选项(Optimize Mesh Data)，对于已经打包并且放到了Streaming Assets中的AssetBundle文件有效果吗？模型资源里有个Optimize Mesh，是否能达到同样的效果？

二、资源使用

纹理相关

Q1、同样的包同一个图集，ETC2格式，在红米Note1上会比酷派的内存会大四倍，请问这是什么原因造成的？如果不支持OpenGL 3.0，会造成这么大的影响吗？

Q3、请问Unity引擎中使用什么贴图压缩格式，可以保证在占用内存相对较小的情况下True Color效果和原图相当？同时在iOS和Android平台上图片的压缩格式分别用什么比较合适？有什么需要注意的地方吗?

网格相关

Q1、我有一个特效依赖了两个FBX。我把这两个FBX的这个勾选去掉，Editor运行正常。否则就会宕机，请问这是什么原因？

动画片段相关

音频相关

Q1、请问音频中的 Quality 什么意思？一般设置为多少合适？我拖进去一首歌曲，试了一下 在0 和 100 的情况下区别不大，但是生成的音频文件大小差别很大。

材质相关

Shader相关

Q1、以前端游时代，材质根据Pass不同、光照环境不同可以离线预编译成ShaderCache，运行时并不需要拼材质再实时编译，只要加载二进制代码就好了。那Unity有没有做这件事呢？我们是根据平台和环境预编译的Shader。

Q2、相同效果前提下，就性能而言，Shader 是用 V&F 还是Surface好？

字体相关

Q1、我们现在为了美观，需要同时使用2套字体。但是每增加一套字体，就会内存增加50MB左右。请问你们在优化其他Unity游戏时，怎么处理类似情况的？

粒子系统

Lightmap

Q1、Lightmap在PC上显示正常，但是转到Android平台上存在色差，颜色普遍偏暗。

分布式实时监控系统（不断更新）

为什么需要跟踪系统

故障快速定位

恶性循环的形成

现状把握&决策支持

启示1：跟踪系统的两个重要需求

启示2：跟踪系统的三大设计要点

低损耗（Low overhead）

应用级透明（Application-level transparency）

扩展性（Scalability）

启示3：跟踪系统的KPI

启示5：准确定位延迟问题

启示8：Dapper系统的核心构成

Q1、请问音频中的 Quality 什么意思？一般设置为多少合适？我拖进去一首歌曲，试了一下在0 和 100 的情况下区别不大，但是生成的音频文件大小差别很大。