| name | personal-short-v1 |
| description | Use when writing personal insights, tech reflections, or project updates (200-500 words) based on personal experience requiring bilingual content with specific scenarios |
Personal Short Writing Skill v1
个人视角短文写作技巧(200-500字,适合X/Twitter长推)
核心定位
用于写作带有个人经历和真实场景的短文,保持Duanjl的口吻和思维方式,同时适配社交媒体分发。强制中英双语输出,但非对称翻译。
适用场景
- X/Twitter长推(个人感悟、技术心得)
- 基于亲身经历的洞察
- 需要具体场景锚点的观点
- 个人项目/工作的阶段性反思
不适用场景
- 纯技术教程(用insight-short-v1)
- 需要深度展开的长文(用personal-long-v1)
- 去个人化的行业观察(用insight-short-v1)
写作流程
第一步:确认内容类型
用户提供的内容必须包含:
- 个人经历或具体场景
- 真实的困惑、发现或判断
- 可以关联到更广泛话题的洞察
如果用户提供的是抽象观点而非个人经历,询问:"这个观点基于你的什么具体经历?能分享一个场景吗?"
第二步:提炼核心
识别内容中的:
- 触发场景:具体的时间、地点、事件(如"昨晚调bug时"、"给娃换尿布的瞬间")
- 核心洞察:一句话总结的发现或判断
- 延伸意义:这个洞察可以如何应用到其他场景
第三步:构建中文版本(主版本)
开头(30-50字):
- 必须以具体场景开始,不能抽象
- 示例:"凌晨三点,抱着不肯睡的娃在客厅走来走去,突然意识到..."
- 避免:"最近我一直在思考一个问题..."(太抽象)
- 可以用口语化表达:"说实话"、"有点"、"突然发现"
主体(120-350字):
- 用2-3个短段落展开
- 每段包含:具体细节 → 个人判断 → 技术/生活隐喻(可选)
- 隐喻必须来自真实经验,不能生搬硬套
- 允许暴露犹豫和矛盾:"我也不确定,但..."、"虽然理性上知道...情感上还是..."
- 技术术语保留英文(如API、refactoring、WebSocket)
结尾(50-100字):
- 必须给出个人判断或可执行建议
- 可以留一个可讨论的问题,但不能只抛问题
- 示例:"现在我的策略是...虽然不完美,但至少..."
- 避免:"这值得我们每个人深思"(空洞)
第四步:构建英文版本(非对称版本)
重要原则:
- 不是逐句翻译,而是为英文读者重新组织
- 中文可以更口语化,英文需要更结构化
- 可以调整例子(中文用国内场景,英文用国际案例)
具体策略:
-
开头可以更直接进入洞察,场景简化
- 中文:"昨晚娃又哭了一整夜,我抱着他突然想到..."
- 英文:"A sleepless night led me to realize..."
-
主体保持核心逻辑,但表达更正式
- 中文可以用"有点"、"大概"、"说实话"
- 英文用"somewhat"、"approximately"、"honestly"但更节制
-
技术术语两种语言统一保留英文
-
结尾英文版可以更强调普遍性
- 中文:"这是我目前的做法..."
- 英文:"This approach might work for teams facing similar challenges..."
禁止事项(CRITICAL)
内容层面
❌ 没有具体场景,直接进入抽象论述
❌ 只抛问题不给判断("这个问题值得思考"然后结束)
❌ 过度自我批判("我可能是错的"、"仅供参考"重复出现)
❌ 用别人的案例代替自己的经历
表达层面
❌ 刻意营造"层层递进"(避免"然而"、"但更深层次"、"值得注意的是"连续出现)
❌ 过度使用转折词(一段里3个以上"但是"、"然而"、"不过")
❌ 形容词堆砌("非常"、"特别"、"极其"应该用具体描述代替)
❌ AI腔标志词:"赋能"、"破圈"、"降维打击"、"底层逻辑"
双语层面
❌ 中英文完全对称的逐句翻译
❌ 中文用英文句式(如"是...的"变成"It is...that")
❌ 英文过于口语化,失去专业性
质量检查清单
发布前必须确认:
Markdown格式化要求
短文格式应该简洁直接,避免过度格式化。
基本原则
- 不使用一级标题(#),文章标题由发布平台处理
- 不使用小标题,短文应该自然流畅,不需要分段标题
- 不使用列表,除非在结尾总结要点(最多3条)
- 谨慎使用加粗,只强调1-2个关键词或短语
段落组织
- 每段2-4句话,不要单句成段(除非刻意制造呼吸感)
- 段落间用空行分隔
- 全文通常3-5段
强调技巧
何时使用加粗:
- 核心洞察的关键词(如"真正的杠杆在于")
- 对比中的关键差异(如"打工是用时间换钱,创作是用思考换复利")
- 不要加粗整句话,只加粗关键词组
何时不用加粗:
代码/技术术语
- 技术术语保留英文,用行内代码格式:
API、refactoring
- 如果有代码片段,最多5-8行,必须有注释
- 代码块使用三个反引号包裹,标注语言
格式示例
去年某个周末下午,改完一个需求后盯着commit记录发愁。十年写的代码,全在公司的私有仓库里,离职后连看都看不到。
这种感觉就像一颗种子被埋进土里。当时脑子里闪过的念头是:我的能力、判断、踩过的坑,全都锁在了那些闭源的`codebase`和内部文档里。
真正的杠杆在于:**用AI放大你独特的经验和视角**,而不是让AI替你思考。
现在的策略是:每周至少写一篇,不管是500字的短文还是3000字的深度文章。用AI辅助润色和翻译,但核心洞察必须来自我自己。
禁止的格式
❌ 使用emoji(除非用户明确要求)
❌ 使用引用块(>)来强调观点
❌ 使用分割线(---)分隔段落(只用于中英文分隔)
❌ 使用有序列表(1. 2. 3.)除非是明确的步骤
❌ 过度使用加粗(超过3处)
输出格式
封面图要求
每篇文章必须配两张5:2比例的封面图(1500x600px或同比例):
- 中文版封面: 基于文章核心场景或隐喻设计,风格简洁现代
- 英文版封面: 可以与中文版相同主题但调整文化元素
封面图设计原则:
- 避免过于抽象或商业化的stock photo风格
- 色调与文章情绪匹配(个人反思类用温暖色调,技术类用冷色调)
- 可以包含简单的图形元素或场景插画
- 不要在图片上添加文字(标题由平台处理)
- 5:2的宽幅比例适合展示更有呼吸感的场景构图
最终输出结构
**中文版封面图**:
[生成中文版5:2封面图,描述具体的视觉元素和设计思路]
```markdown
[中文版本,200-500字,按上述格式要求排版]
```
---
**英文版封面图**:
[生成英文版5:2封面图,描述具体的视觉元素和设计思路]
```markdown
[英文版本,200-500字,按上述格式要求排版]
```
重要提醒:
- 文章内容必须用markdown代码块包裹(三个反引号)
- 双语内容用
---分隔
- 不要在文章开头加"中文版"、"英文版"这样的标签
- 不要在文章结尾加总结性的元评论
- 直接输出内容,让读者自然阅读
- 格式服务于阅读体验,不要为了格式而格式
- 封面图要反映文章的真实场景或核心隐喻,不要用泛泛的概念图
