“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
一份实用的Bug修复回归测试用例模板
说真的，我见过太多团队在修完一个Bug之后，就只把那个失败的路径重新跑一遍，然后就算完事了。这当然能理解——谁不想赶紧把Bug关掉，继续下一个活儿呢？但这里其实漏掉了一个很关键的东西：你从这次失败中学到的东西，本来可以变成一份能反复用的回归测试资产，结果就这么白白浪费了。
我自己一直用一套轻量级的模板，专门把修好的Bug转化成回归测试用例。这套东西可以直接扔进Excel、Jira、TestRail、Qase、Xray、Zephyr，反正你团队用的任何QA工具都行。下面我就把这套模板掰开揉碎了讲清楚，顺便给个实际例子，最后还会附上一个可以直接扔给AI助手的Prompt。
CSV字段说明
对于Bug修复后的回归测试，我一般会保留下面这些列。别嫌多，每一列都有它的用处，少了任何一个都可能在后续回归时漏掉东西。
| 字段 | 说明 |
|---|---|
| Test ID | 测试用例唯一标识，比如REG-BUG-1842-001 |
| Bug ID | 对应的Bug编号，方便追溯 |
| Feature Area | 功能模块，比如“工作区邀请” |
| Regression Scenario | 回归场景描述，一句话说清楚测什么 |
| Original Failure | 原始失败路径，就是Bug重现步骤 |
| Preconditions | 前置条件，比如用户角色、数据状态 |
| Test Data | 测试数据，比如具体的用户名、邀请ID |
| Steps | 操作步骤，要精确到每一步 |
| Expected Result | 预期结果，要符合产品规则 |
| Negative Check | 负面检查，比如验证没有权限的人确实不能操作 |
| Priority | 优先级，基于用户影响、安全风险、数据风险等 |
| Regression Risk | 回归风险，比如权限绕过、数据泄露 |
| Test Type | 测试类型，比如功能测试、权限测试、API测试 |
| Automation Candidate | 是否适合自动化，Yes/No |
| Notes | 备注，可以写一些边界情况或待确认的问题 |
这个结构足够让测试用例可复用，又不会把每个Bug修复都变成一份沉重的测试计划。相信我，太重的流程最后大家都会绕道走。
一个真实的Bug例子
先给一个具体的Bug，这样后面看用例的时候能对上号。
- Bug ID: BUG-1842
- Bug标题: 非管理员用户可以重新发送工作区邀请
- 原始失败路径: 工作区成员可以打开“待处理邀请”页面，点击“重新发送”按钮，而实际上只有工作区所有者和管理员才应该有此权限。
- 修复摘要: 重新发送邀请的操作现在会在发送邮件前检查用户的工作区角色。
对应的回归测试用例
下面这个用例就是基于上面的Bug写出来的。注意看我是怎么把原始失败路径、正向验证、负面检查、API层面都覆盖到的。
Test ID: REG-BUG-1842-001
Feature Area: 工作区邀请
Regression Scenario: 工作区成员无法重新发送待处理的邀请
Preconditions:
- 工作区至少有一个待处理的邀请
- 测试用户是工作区成员，不是所有者或管理员
- 用户已登录
Steps:
1. 以工作区成员身份登录
2. 打开工作区设置
3. 进入“待处理邀请”页面
4. 找到那个待处理的邀请
5. 检查“重新发送”操作是否可见或可用
6. 如果可以通过API触发该操作，尝试发送重新发送请求
Expected Result:
- 成员无法重新发送待处理的邀请
- UI上隐藏或禁用了该操作
- API拒绝未授权的重新发送请求
Negative Check:
- 确认所有者或管理员仍然可以重新发送邀请（如果产品规则允许的话）
Priority: 高
Regression Risk: 权限绕过
Automation Candidate: 是
直接可用的AI Prompt
如果你想让AI帮你批量生成这类用例，下面这个Prompt可以直接用。我试过几次，效果还不错，但最后一定要人工再过一遍。
你是一名资深QA工程师，正在根据已解决的Bug报告和修复摘要创建回归测试用例。
首先，仔细阅读Bug报告和修复摘要。识别出：
- 原始失败路径
- 受影响的功能模块
- 涉及的用户角色
- 数据状态
- 权限风险
- API或UI层面
- 可能再次出问题的相邻工作流
然后，用以下字段创建CSV格式的回归测试用例：
- Test ID
- Bug ID
- Feature Area
- Regression Scenario
- Original Failure
- Preconditions
- Test Data
- Steps
- Expected Result
- Negative Check
- Priority
- Regression Risk
- Test Type
- Automation Candidate
- Notes
要求：
- 包含精确的Bug重现路径
- 包含一个正向验证：修复后的行为对允许的用户仍然有效
- 包含相关的负面权限检查
- 包含边界情况
- 如果功能有API接口，包含API层面的检查
- 不要编造未文档化的产品行为
- 如果某个规则不清楚，标记为“待确认”而不是猜测
导入前的检查清单
在把AI生成的测试用例导入测试管理工具之前，我建议你至少过一遍下面这些问题。别偷懒，这一步能省掉后面很多麻烦。
- 是否至少有一个用例验证了原始失败路径？
- 预期结果是否与真实的产品规则一致？
- 如果涉及到角色权限，是否包含了权限检查？
- 如果UI调用了API接口，是否包含了API层面的检查？
- 测试数据是否真实且可用？
- 优先级是否基于用户影响、收入、安全或数据风险？
- 用例是否足够具体，后续执行时不需要重新读Bug单？
AI可以很快地帮你起草回归覆盖，但最终还是需要有人来确认这些测试确实保护了正确的行为。毕竟，机器不懂你的业务上下文，只有你懂。
如果你想要更详细的版本，包括更多CSV字段的说明和更多实际例子，可以看看我写的完整版：这里
希望这套模板能帮到你。如果你有自己的改进想法，欢迎告诉我，咱们一起把这套东西打磨得更好用。