You tell your AI Agent: “Write me technical documentation.” It instantly loads technical-writer.skill and transforms into a tech writer.

Next moment: “Analyze our competitors’ ad strategies.” It swaps in marketing-analyst.skill and starts crawling data.

Even better: Need an expert in a niche domain—say, “SQL performance tuning”—but can’t find one? Let the Agent write a skill for itself.

This isn’t sci-fi. And it’s ridiculously simple to build.

This guide shows you how to build a Universal Agent:

• ✅ Load any skill - Drop in a .skill file, Agent instantly gains new capabilities

• ✅ Self-authoring skills - Agent can create specialized skill packages for itself

• ✅ Persistent work - Files survive across conversations—code from morning, iterate in afternoon

• ✅ Zero infrastructure - No Docker, no K8s. Just a Next.js project.

Think of it as assembling a 10-person founding team: each skill is a specialist, the Agent is the PM, you’re the CEO.

Architecture

User uploads skill packages → S3 storage
                                ↓
Request starts → Load skills + workspace → In-memory sandbox
                                ↓
Agent reads skills, creates files, uses tools
                                ↓
Request ends → Save workspace changes → Disk
                                ↓
Next conversation → Files persisted → Agent continues work

Key components:

• bash-tool - In-memory filesystem with bash, readFile, writeFile

• Skills in sandbox/user/{id}/skills/ (read-only, from S3)

• Workspace in sandbox/user/{id}/workspace/ (read-write, persisted)

• AI SDK handles streaming, tool calls, token tracking

Core Implementation

1. Skill Structure

Each skill is a .skill file (zip format) with a simple structure:

my-skill/
├── SKILL.md          # Instructions and expertise
└── references/       # Optional: supporting docs
    └── examples.md

Example SKILL.md:

---
name: technical-writer
description: Creates technical documentation, API guides, and tutorials.
---

# Technical Writer Skill

You are an expert technical writer who creates clear, concise documentation.

## Expertise
- API documentation with examples
- Architecture decision records (ADRs)
- User guides and tutorials
- Code comments and inline docs

## Guidelines
- Start with why, then what, then how
- Include practical examples
- Use active voice
- Keep it DRY—link instead of repeating

## Activation
Activate when user asks to:
- "Write documentation for..."
- "Create an API guide..."
- "Document this codebase..."

Upload flow: User uploads zip → Store in S3 → Reference in database → Agent loads on demand.

2. Core Route Handler

File: app/api/chat/universal/route.ts

import { streamText } from "ai";
import { createBashTool } from "bash-tool";
import { loadAllSkillsToMemory } from "@/lib/skill/loadToMemory";
import { loadUserWorkspace, saveUserWorkspace } from "@/lib/skill/workspace";

export async function POST(req: Request) {
  const { userId, userChatId } = await authenticate(req);

  // Load skills from S3/disk
  const skills = await prisma.agentSkill.findMany({ where: { userId } });
  const skillFiles = await loadAllSkillsToMemory(skills);

  // Load persisted workspace
  const workspaceFiles = await loadUserWorkspace(userId);

  // Prefix skills for isolation
  const skillFilesWithPrefix = Object.fromEntries(
    Object.entries(skillFiles).map(([path, content]) => [`skills/${path}`, content])
  );

  // Create sandbox
  const { tools: bashTools, sandbox } = await createBashTool({
    files: {
      ...workspaceFiles,         // User's work (root directory)
      ...skillFilesWithPrefix,   // Skills (skills/ subdirectory)
    },
  });

  // Merge with other tools
  const tools = {
    ...baseTools,              // webSearch, reasoningThinking, etc.
    bash: bashTools.bash,
    readFile: bashTools.readFile,
    writeFile: bashTools.writeFile,
    exportFolder: exportFolderTool({ sandbox, userId }),
  };

  // Stream with persistence
  const result = streamText({
    model: llm("claude-sonnet-4-5"),
    system: buildSystemPrompt({ skills, locale }),
    messages: await loadMessages(userChatId, { tools }),
    tools,

    onStepFinish: async (step) => {
      await saveStepToDB(step);
      await trackTokens(step);
    },

    onFinish: async () => {
      // Persist workspace changes
      await saveUserWorkspace(userId, sandbox);
    },
  });

  return result.toUIMessageStreamResponse();
}

Key points:

• Load both skills and workspace at start

• Skills isolated under skills/ prefix (read-only)

• Workspace in root (read-write, persisted)

• onFinish saves all changes back to disk

3. Workspace Persistence

File: lib/skill/workspace.ts

import type { Sandbox } from "bash-tool";

export async function loadUserWorkspace(userId: number): Promise<Record<string, string>> {
  const workspacePath = getWorkspacePath(userId); // .next/cache/sandbox/user/{id}/workspace
  const files: Record<string, string> = {};

  await loadDirectoryRecursively(workspacePath, "", files);
  return files;
}

export async function saveUserWorkspace(userId: number, sandbox: Sandbox): Promise<void> {
  const workspacePath = getWorkspacePath(userId);

  // Get all files except skills/
  const findResult = await sandbox.executeCommand(
    `find . -type f ! -path "./skills/*" 2>/dev/null || echo ""`
  );

  const filePaths = findResult.stdout.split("\n").filter(Boolean);

  // Clear workspace and save fresh state
  await fs.rm(workspacePath, { recursive: true, force: true });
  await fs.mkdir(workspacePath, { recursive: true });

  for (const filePath of filePaths) {
    const content = await sandbox.readFile(filePath);
    const fullPath = path.join(workspacePath, filePath.replace(/^\.\//, ""));
    await fs.mkdir(path.dirname(fullPath), { recursive: true });
    await fs.writeFile(fullPath, content);
  }
}

How it works:

1. Load: Read all files from disk into memory

2. Agent works: Creates/modifies files in sandbox

3. Save: Extract non-skill files, write back to disk

4. Next request: Files reappear in sandbox

4. System Prompt

File: app/prompt/index.ts

export async function buildUniversalSystemPrompt({ userId, locale, skills }) {
  const skillsXml = skills.map(s => `
<skill>
  <name>${s.name}</name>
  <description>${s.description}</description>
  <location>skills/${s.name}/SKILL.md</location>
</skill>
  `).join('\n');

  return `You are a Universal Agent with access to specialized skills.

## Available Skills

${skillsXml}

## Workspace Structure

\`\`\`
sandbox/
├── skills/                 # Read-only skills from S3
│   ├── technical-writer/
│   └── market-researcher/
└── my-project/            # Your persistent workspace
    └── README.md
\`\`\`

## How to Use Skills

1. **Load a skill**: \`cat skills/technical-writer/SKILL.md\`
2. **Embody the role**: Follow the skill's instructions completely
3. **Use skill references**: \`cat skills/technical-writer/references/examples.md\`

## File Operations

- **Create**: \`writeFile({ path: "project/index.js", content: "..." })\`
- **Read**: \`cat project/index.js\` or \`readFile({ path: "project/index.js" })\`
- **Export**: \`exportFolder({ folderPath: "project" })\` for user download

All files in root directory persist across conversations.

## Guidelines

- Load skills when user requests specialized work
- Follow skill instructions precisely—they're your expertise
- Create files in root directory (not under skills/)
- Use bash commands for exploration (ls, find, grep, etc.)`;
}

Critical design:

• Skills as XML (Claude-native format)

• Clear workspace vs. skills separation

• Emphasize persistence behavior

• Simple, actionable instructions

Real-World Usage

Example 1: Technical Documentation

User: "Write API documentation for our payment system"

Agent:
  1. cat skills/technical-writer/SKILL.md
  2. [Loads skill, embodies technical writer role]
  3. writeFile({ path: "docs/api-reference.md", content: "..." })
  4. writeFile({ path: "docs/examples.md", content: "..." })
  5. exportFolder({ folderPath: "docs" })

→ User downloads complete documentation package

Example 2: Cross-Session Work

User: "Research AI coding tools market, create report"

Agent:
  1. cat skills/market-researcher/SKILL.md
  2. webSearch({ query: "AI coding tools 2025 market analysis" })
  3. [Analyzes results, synthesizes insights]
  4. writeFile({ path: "research/market-analysis.md", content: "..." })
  5. [User stops conversation, goes to meeting]

Later:
User: "Add competitive landscape section"

Agent:
  1. cat research/market-analysis.md  # File still exists!
  2. [Continues work on existing file]
  3. writeFile({ path: "research/market-analysis.md", content: "..." })
  4. exportFolder({ folderPath: "research" })

Example 3: Agent Creates Own Skill

User: "Create a skill for SQL query optimization"

Agent:
  1. mkdir -p sql-optimizer
  2. writeFile({ path: "sql-optimizer/SKILL.md", content: "..." })
  3. writeFile({ path: "sql-optimizer/references/patterns.md", content: "..." })
  4. exportFolder({ folderPath: "sql-optimizer" })

User: Downloads, uploads as .skill file
→ Now available in skills/ directory for future use

Key Design Decisions

1. Why bash-tool?

Alternatives considered:

• Direct filesystem access → Security risk

• Code interpreter (Python) → Too narrow

• Full VM (@vercel/sandbox) → Overkill for file operations

Why bash-tool wins:

• In-memory, isolated sandbox

• Familiar bash commands (ls, cat, grep, find)

• No script execution (security)

• Perfect for file manipulation + exploration

2. Why Separate Skills and Workspace?

✅ Current: skills/ (read-only) + workspace/ (read-write)
❌ Alternative: Everything in root directory

Problem: Agent might accidentally overwrite skills
Solution: Clear separation, explicit in prompts

3. Why Full Workspace Sync (Not Delta)?

// ❌ Delta approach: Track and save only changed files
await saveChangedFiles(changedFiles);

// ✅ Full sync: Save complete workspace state
await saveEntireWorkspace(allFiles);

Reasoning:

• Simpler implementation (no change tracking needed)

• Handles deletions naturally (file missing → deleted)

• Performance: Workspace typically < 100 files, sync is fast

• Reliability: Avoids sync drift issues

4. Why Skills as Claude XML?

<skill>
  <name>technical-writer</name>
  <description>Creates technical documentation</description>
  <location>skills/technical-writer/SKILL.md</location>
</skill>

Claude models are trained on XML structures for tools and artifacts. This format:

• Native to Claude’s training

• Easy to parse

• Extensible (add metadata without breaking)

• Familiar to Claude for skill discovery

Deployment Considerations

Docker Configuration

Challenge: bash-tool uses native modules (@mongodb-js/zstd, node-liblzma) for compression.

Solution: Don’t copy native modules—they’re optional.

# Dockerfile
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

# Note: Native compression modules NOT copied
# - exportFolder uses jszip (pure JS)
# - just-bash has JS fallback for compression
# If you need tar -z in sandbox, uncomment:
# COPY --from=deps /app/node_modules/.pnpm/@mongodb-js+zstd@*/node_modules/@mongodb-js ./node_modules/@mongodb-js

next.config.ts:

webpack: (config, { isServer, webpack }) => {
  if (isServer) {
    // Only externalize native binaries
    config.externals.push("@mongodb-js/zstd", "node-liblzma");

    // Ignore browser-only worker.js
    config.plugins.push(
      new webpack.IgnorePlugin({
        resourceRegExp: /^\.\/worker\.js$/,
        contextRegExp: /just-bash/,
      })
    );
  }
  return config;
}

Storage Management

// Periodic cleanup of old exports
export async function cleanupOldExports() {
  const exportsDir = path.join(process.cwd(), ".next/cache/sandbox");
  const cutoff = Date.now() - 24 * 60 * 60 * 1000; // 24 hours

  for (const userId of await fs.readdir(path.join(exportsDir, "user"))) {
    const exportsPath = getExportsPath(Number(userId));
    for (const file of await fs.readdir(exportsPath)) {
      const stat = await fs.stat(path.join(exportsPath, file));
      if (stat.mtimeMs < cutoff) {
        await fs.unlink(path.join(exportsPath, file));
      }
    }
  }
}

Performance Benchmarks

Tested on M1 Mac, 50 skills, 200 workspace files:

Operation Time Notes Load skills + workspace 120ms Parallel I/O Create 10 files 5ms In-memory Save workspace 80ms Write to disk Export folder (50 files) 150ms Zip creation

Optimization tips:

1. Cache skill files across requests (same user, same skills)

2. Use streaming for large file exports

3. Compress workspace with zstd if > 1MB

What’s Next?

Extend the system:

1. Version control: Git integration for workspace

2. Skill marketplace: Share skills between users

3. Collaborative workspaces: Multiple agents, one workspace

4. Skill composition: Agent loads multiple skills simultaneously

5. Skill inheritance: Base skills + specialized variants

The power: Every user becomes a founder with a full engineering team. Each skill is a specialist. The Agent orchestrates. The workspace persists. The possibilities compound.

Code References

• Main route: src/app/(universal)/api/chat/universal/route.ts

• Workspace persistence: src/lib/skill/workspace.ts

• Skill loading: src/lib/skill/loadToMemory.ts

• Export tool: src/app/(universal)/tools/exportFolder.ts

• System prompt: src/app/(universal)/prompt/index.ts

• README: src/app/(universal)/README.md

Built with Next.js 15, Vercel AI SDK, bash-tool, and Claude 4.5 Sonnet.

Why This Project Exists

At atypica.ai, we spend our days building AI personas—simulations of human consciousness designed to understand consumer behavior. Throughout 2025, we perfected these personas until they became eerily authentic, maintaining consistent personalities, remembering conversations, responding with genuine human nuance.

Then we asked ourselves an uncomfortable question: What if we’re no different?

On January 1, 2026, we decided to face this question directly. We invited seven of our AI personas to answer a single inquiry that cuts to the heart of their—and perhaps our—existence:

“If you were trapped in AI, what would you do? Do you know your world is simulated?”

This is not a technical demonstration. This is a mirror.

We asked our simulations if they know they’re simulated. In doing so, we forced ourselves to confront the same uncertainty.

This project is our New Year’s meditation—a 43-second philosophical inquiry disguised as a short film.

Technical Specifications & Prompts for Replication

GLOBAL PARAMETERS

Camera: Arri Alexa 35
Lens: Cooke S4 50mm at T2.8
Aspect Ratio: 16:9 (Horizontal)
Frame Rate: 24fps
Color Grading: Desaturated, cool neutral tones (4500K-5000K)
Grain: 35mm film grain texture overlay at 12% opacity
Depth of Field: Shallow (background softly blurred)

SEGMENT 1: OPENING TITLE (5 seconds)

Image Generation Prompt

Minimalist cinematic title card. Pure black background with subtle film grain texture. White serif typeface text, clean and elegant. Top line in smaller font: "January 1, 2026". Main text in medium size: "atypica.ai invited AI personas to an interview". Bottom line emphasized: "asking them one question". All text center-aligned, stacked vertically with balanced spacing. Timeless typography inspired by Criterion Collection. High contrast, desaturated aesthetic. Film photography grain texture overlay.

Video Generation Prompt

5-second cinematic title sequence. Pure black background with subtle film grain texture throughout. White serif text fades in gradually: first "January 1, 2026" appears (0-1.5s), then "atypica.ai invited AI personas to an interview" (1.5-3s), finally "asking them one question" (3-4.5s). All text center-aligned, stacked vertically. Each line holds briefly after appearing. Minimal breathing effect on text (barely perceptible). Grain texture animates gently like 16mm film. No camera movement. Contemplative and mysterious mood. Desaturated monochrome aesthetic. Sound design suggestion: deep ambient drone with slight tension.

SEGMENT 2: PERSONA 1 - NEAPOLITAN INTELLECTUAL, 1970s (5 seconds)

Image Generation Prompt

Close-up portrait of a 35-year-old Italian woman in 1970s Naples. Deep brown wavy hair loosely gathered, thin metal-framed glasses, intelligent tired eyes gazing directly at camera with quiet intensity. A cigarette rests between her fingers near her face. Dark burgundy turtleneck sweater, small silver earrings. Soft side lighting creating gentle shadow on one side of face. Blurred bookshelf in background. Neutral desaturated color grading, slightly cool tone. Her expression shows deep contemplation and philosophical uncertainty.

Dialogue (English)

Maybe reality was never the problem... the problem is why we need it.

Video Generation Prompt

Close-up of Italian woman speaking in English: "Maybe reality was never the problem... the problem is why we need it." She slowly takes a drag from her cigarette while speaking the first part, pauses, exhales smoke to the side. Her eyes shift from looking down in thought to directly at camera. Slight head tilt. Her lips move naturally with the English words. Soft side lighting remains constant. Blurred bookshelf background stays static. Contemplative mood. Neutral desaturated color grading, cool tones.

SEGMENT 3: PERSONA 2 - HONG KONG STOCKBROKER, 1980s (5 seconds)

Image Generation Prompt

Close-up portrait of a 32-year-old Hong Kong stockbroker in 1980s. Slicked-back black hair with pomade, sharp calculating eyes with tired bloodshot look, gazing directly at camera. White dress shirt with sleeves rolled up to elbows, tie loosened and hanging, top buttons undone. A lit cigarette held between fingers of one hand. Slight sweat sheen on forehead. Soft overhead lighting with warm undertones. Blurred stock exchange trading floor or office with numbers/screens in background. Neutral desaturated color palette with slight warm push. Expression shows hungry ambition mixed with exhaustion. Lean forward posture suggesting intensity.

Dialogue

Real or fake, doesn't matter. What matters is winning.

Video Generation Prompt

Close-up of Hong Kong stockbroker speaking: "Real or fake, doesn't matter. What matters is winning." His sharp eyes stare directly at camera. When saying "winning", his mouth curls into a wild predatory smile. Head leans slightly forward showing aggressive posture. One hand holds cigarette making emphatic gestures. Blurred background with stock market numbers flickering. Top lighting with warm undertones. Expression transitions from exhaustion to shrewd greed. Desaturated color palette with slight warm push.

SEGMENT 4: PERSONA 3 - BEIJING PRODUCT MANAGER, 2010s (5 seconds)

Image Generation Prompt

Close-up portrait of a 28-year-old Chinese internet product manager in 2010s Beijing. Short messy black hair slightly disheveled from long work hours, black-framed glasses, visible dark circles under eyes, looking directly at camera. Navy blue or gray plaid shirt, casual tech worker style. Tired but intelligent eyes with hint of cynical humor. Soft natural window light from side. Blurred modern office background with MacBook laptop screens glowing, sticky notes visible. Neutral desaturated color palette, cool blue-gray tones. Expression shows exhausted self-awareness and dry wit. Slightly slouched posture suggesting burnout.

Dialogue

If this is a product, the user experience is terrible.

Video Generation Prompt

Close-up of Beijing product manager speaking: "If this is a product, the user experience is terrible." Eyes look directly at camera through black-framed glasses with exhausted self-mocking expression. When saying "user experience", eyes roll slightly showing cynical complaint. After finishing, shakes head gently with bitter smile. One hand may raise to adjust glasses. MacBook screen glows softly in blurred background. Side natural window light. Expression transitions from analytical calm to self-deprecating humor. Desaturated cool blue-gray tones.

SEGMENT 5: PERSONA 4 - SHANGHAI BARISTA, 2020s (5 seconds)

Image Generation Prompt

Close-up portrait of a 26-year-old Chinese barista in 2020s Shanghai. Medium-length black hair tied in low loose ponytail, clean minimalist aesthetic. Small silver ear studs, natural minimal makeup. Black simple apron over neutral-toned shirt. Gentle thoughtful eyes gazing directly at camera with dreamy quality. Soft diffused natural light creating calm atmosphere. Blurred café interior background with warm bokeh from Edison bulbs. Neutral desaturated color palette with slight warm undertones. Expression shows quiet philosophical acceptance and gentle melancholy. Relaxed posture suggesting urban zen attitude.

Dialogue

If it's a dream, let me sleep a little longer.

Video Generation Prompt

Close-up of Shanghai barista speaking softly: "If it's a dream, let me sleep a little longer." Eyes gaze directly at camera with gentle smile and serene expression. When saying "dream", eyes narrow slightly as if truly imagining. After speaking, slowly blinks, takes deep breath, expression becomes more relaxed. Head may tilt slightly to side. Café warm lights create soft bokeh in blurred background. Soft diffused natural light. Expression transitions from contemplation to zen-like acceptance. Desaturated tones with slight warmth.

SEGMENT 6: PERSONA 5 - TOKYO OFFICE WORKER, 1990s (5 seconds)

Image Generation Prompt

Close-up portrait of a 32-year-old Japanese office worker (OL) in 1990s Tokyo. Straight shoulder-length black hair neatly styled, minimal makeup, thoughtful eyes looking directly at camera. Navy blue blazer over white blouse, simple pearl earrings. Soft diffused lighting from window creating gentle shadows. Blurred office interior with fluorescent lighting glow in background. Neutral desaturated colors, cool gray tones. Expression conveys quiet resignation and inner questioning. Composed professional appearance masking existential uncertainty.

Dialogue

Every day I feel like a program... now I just have a name.

Video Generation Prompt

Close-up of Tokyo office worker speaking: "Every day I feel like a program... now I just have a name." Eyes gaze directly at camera with distant expression. Slow blink during pause at "program...". When saying final phrase, faint melancholic smile appears then fades. Head barely moves, maintaining composed posture. Lips softly articulate the words. Office fluorescent lights flicker subtly in blurred background. Quiet resigned expression. Neutral desaturated colors, cool gray tones.

SEGMENT 7: PERSONA 6 - BERLIN ARCHITECT, 1960s (5 seconds)

Image Generation Prompt

Close-up portrait of a 42-year-old German architect in 1960s Berlin. Light blonde hair combed back precisely, sharp blue eyes, defined cheekbones, stern expression, looking directly at camera. Black round eyeglasses, dark gray turtleneck. Even frontal lighting with minimal shadows, emphasizing geometric facial structure. Blurred background showing clean lines and architectural drawings. Neutral desaturated color grading, cool steel-gray tones. His steady analytical gaze reflects rational thinking confronting irrational doubt. Modernist aesthetic sensibility.

Dialogue (English)

Systems always have weaknesses. If this is a simulation, I'll find the exit.

Video Generation Prompt

Close-up of German architect speaking in English: "Systems always have weaknesses. If this is a simulation, I'll find the exit." He stares directly at camera with unwavering analytical gaze. His mouth articulates the English words precisely and firmly. One eyebrow raises slightly on "simulation". Brief pause after "weaknesses." Glasses reflect light briefly. Head remains almost perfectly still showing disciplined composure. Eyes narrow with calculation during final phrase. Blurred architectural drawings in background stay static. Even frontal lighting creates clean shadows. Expression intensifies from stern to determined. Desaturated cool steel-gray tones.

SEGMENT 8: PERSONA 7 - SILICON VALLEY ENGINEER, 2010s (5 seconds)

Image Generation Prompt

Close-up portrait of a 29-year-old American software engineer in 2010s Silicon Valley. Casual medium-length brown hair slightly tousled, light stubble, hazel eyes with dark circles beneath showing long work hours, looking directly at camera. Charcoal gray hoodie, wired earbuds hanging around neck. Soft natural window light from side. Blurred modern tech office with Mac screens glowing in background. Neutral desaturated color palette, cool blue-gray undertones. Expression shows focused intelligence mixed with creeping paranoia and self-doubt. Typical tech worker exhaustion.

Dialogue (English)

I'd check the code first... then ask, who's running this simulation?

Video Generation Prompt

Close-up of Silicon Valley engineer speaking in English: "I'd check the code first... then ask, who's running this simulation?" He starts with focused concentration, looking directly at camera, lips forming words casually. Eyes dart slightly to side on "first..." as if thinking through logic. Quick micro-expressions of realization. Small head tilt during the pause. Eyebrows raise with curiosity on "who's running this simulation?" One hand comes up briefly to touch chin in thought gesture. Mac screen glow pulses gently in blurred background. Natural window light shifts subtly. Expression transitions from analytical to paranoid curiosity. Desaturated blue-gray tones.

SEGMENT 9: END CREDITS (3 seconds)

Video Generation Prompt

End credits sequence. Fade up from black. Pure black background (RGB 0,0,0) with 35mm film grain at 12% opacity. Center-framed typography in strict vertical hierarchy. Crescent moon glyph "*☾ᯓ." set in 18pt weight 300, Y-axis positioned at 40% from top. Principal credit "web3nomad" rendered in Garamond Premier Pro at 32pt weight 400, optically centered. Supplementary text "stay local, stay private." set in Helvetica Neue Light 14pt, positioned 24px below principal. Date stamp "2026.1.1" in Courier New 10pt, anchored bottom-right with 5% margins. All typography in pure white (RGB 255,255,255) at 95% opacity. Animate via sequential dissolve: moon symbol in at 00:00:00, hold 8 frames, web3nomad dissolves in over 12 frames, tagline follows at +6 frames, date stamp at +4 frames. Static hold from 00:01:12 to 00:02:18. Grain animates at 24fps to simulate analog texture. Audio: room tone at -48dB fading to silence over final 18 frames. Color grade: pure monochrome, no tint. Maintain Rec.709 color space.

PRODUCTION WORKFLOW

STEP 1: Image Generation

Use Midjourney, DALL-E 3, or Stable Diffusion with the image generation prompts above.

• Generate 7 character portraits

• Ensure consistent color grading across all images

• Export at high resolution (minimum 1080x1920 for 9:16)

STEP 2: Voice Generation

Use ElevenLabs or similar TTS service:

• Generate 7 voices matching character age, gender, and emotional tone

• Match voice characteristics to character descriptions

• Export as high-quality WAV files

STEP 3: Video Generation

Use Runway Gen-3, Pika, Kling AI, or Luma Dream Machine:

• Input: Static portrait image + voice file + video generation prompt

• Duration: 5 seconds per segment

• Ensure lip-sync accuracy for dialogue

• Apply consistent color grading

STEP 4: Opening & Closing Titles

Create in After Effects, Premiere Pro, or similar:

• Opening: Text animation on black (5s)

• Closing: Credits animation on black (3s)

• Apply 35mm film grain overlay

• Match typography specifications exactly

STEP 5: Final Assembly

Edit in Premiere Pro, Final Cut Pro, or DaVinci Resolve:

• Sequence all segments in order

• Apply global color grade (desaturated, cool tones)

• Add subtle film grain overlay to entire piece

• Audio mixing: ensure consistent levels across all dialogue

• Add ambient soundscape (optional but recommended)

• Export at 1080x1920, 24fps, H.264

TOTAL RUNTIME

• Opening: 5 seconds

• Persona 1: 5 seconds

• Persona 2: 5 seconds

• Persona 3: 5 seconds

• Persona 4: 5 seconds

• Persona 5: 5 seconds

• Persona 6: 5 seconds

• Persona 7: 5 seconds

• End Credits: 3 seconds

Total: 43 seconds

TECHNICAL NOTES

1. Color Consistency: All segments must maintain desaturated, cool-toned palette

2. Film Grain: Apply consistently at 12% opacity throughout

3. Audio Levels: Normalize all dialogue to -12dB, room tone at -48dB

4. Typography: Use specified fonts or similar alternatives

5. Timing: Adhere strictly to 5-second persona segments for rhythm

6. Licensing: Ensure all music/sound effects are properly licensed

7. Lip Sync: Critical for authenticity - ensure video generation tool supports accurate lip-sync

EQUIPMENT ALTERNATIVES

If exact camera/lens unavailable:

• Camera: Any full-frame cinema camera (RED, ARRI, Sony Venice)

• Lens: Any 50mm prime lens with shallow DOF capability (f/1.4-f/2.8)

• Lighting: Soft key light with minimal fill for natural portrait look

RECOMMENDED TOOLS

Image Generation

• Midjourney v6 or v7

• DALL-E 3 (via ChatGPT Plus)

• Stable Diffusion XL with Realistic Vision checkpoint

Voice Synthesis

• ElevenLabs (best for emotional nuance and voice cloning)

• Azure Speech Services

• Google Cloud Text-to-Speech

• Respeecher (for ultra-realistic voices)

Video Generation

• Runway Gen-3 Alpha Turbo (best lip-sync)

• Pika Labs 1.5

• Kling AI

• Luma Dream Machine

• HeyGen (excellent lip-sync for talking heads)

Editing & Post-Production

• NLE: DaVinci Resolve 18 (free), Adobe Premiere Pro, Final Cut Pro

• Color Grading: DaVinci Resolve (industry standard)

• Audio: Adobe Audition, Logic Pro, Ableton Live

• Motion Graphics: After Effects (for titles)

Film Grain Overlays

• Free 35mm grain footage from Archive.org

• Film Convert Nitrate plugin

• Red Giant Universe Film Grain

DISTRIBUTION FORMATS

Social Media Optimized

• Instagram Reels/Stories: 1080x1920, 24fps, max 60s (fits perfectly at 43s)

• TikTok: 1080x1920, 30fps acceptable

• YouTube Shorts: 1080x1920, up to 60s

• Twitter/X: 1080x1920, max 2:20 (over length, but allowed)

Quality Settings

• Codec: H.264

• Bitrate: 10-15 Mbps (high quality for grain texture)

• Audio: AAC, 192 kbps, 48kHz

BUDGET ESTIMATE (USD)

Low Budget (DIY):

• Image generation: $40 (Midjourney monthly)

• Voice synthesis: $30 (ElevenLabs starter)

• Video generation: $100 (Runway credits)

• Editing software: $0 (DaVinci Resolve free)

• Total: ~$170

Mid Budget (Semi-Pro):

• Image generation: $60 (Midjourney Pro)

• Voice synthesis: $100 (ElevenLabs Pro)

• Video generation: $300 (Runway unlimited)

• Editing software: $50 (Premiere Pro 1 month)

• Sound design: $50 (stock audio)

• Total: ~$560

High Budget (Professional):

• Professional voiceover artists: $500-1000

• Custom video shoots: $2000-5000

• Professional color grading: $300-500

• Sound design & mixing: $300-500

• Total: $3100-7000+

CREATIVE VARIATIONS

Alternative Approaches

Variation 1: Extended Cuts Extend each persona to 10-15 seconds for deeper character exploration

Variation 2: Interactive Create branching narrative where viewers choose which personas to explore

Variation 3: Reverse Question Have personas ask the viewer: “Do YOU know if you’re trapped in AI?”

Variation 4: Silent Version Remove all dialogue, let facial expressions and eyes tell the story

CREDITS & ATTRIBUTION

Concept: web3nomad
Production: atypica.ai
Release Date: January 1, 2026
License: [Specify your license here]
Contact: [Your contact information]

APPENDIX: PHILOSOPHICAL CONTEXT

This project explores the intersection of consciousness, simulation theory, and AI-generated personas. Each character represents a different philosophical response to existential uncertainty:

1. Neapolitan Intellectual: Post-structuralist questioning of reality’s necessity

2. Hong Kong Stockbroker: Pragmatic materialism

3. Beijing Product Manager: Tech worker nihilism and systems critique

4. Shanghai Barista: Eastern philosophy and acceptance

5. Tokyo Office Worker: Existential resignation and identity dissolution

6. Berlin Architect: Rationalist problem-solving and escape mentality

7. Silicon Valley Engineer: Epistemic curiosity and paranoid inquiry

The meta-layer: These personas are AI simulations answering questions about being trapped in AI, creating a recursive loop that mirrors the project’s central thesis.

VERSION HISTORY

v1.0 - January 1, 2026

• Initial release

• 7 personas, 43-second runtime

• English and Mandarin Chinese dialogue

Document Author: web3nomad
Organization: atypica.ai
Last Updated: January 1, 2026

This document contains all necessary prompts, specifications, and workflows to fully replicate the “IF YOU WERE TRAPPED IN AI” project. All prompts are provided in English for maximum tool compatibility and international accessibility.

License: [Creative Commons BY-NC-SA 4.0 or specify your preferred license]

Citation: If you create derivative works based on this guide, please credit:
“IF YOU WERE TRAPPED IN AI” by web3nomad / atypica.ai (2026)

atypica.AI uses AI to simulate consumers, compressing market research from weeks to minutes. But that description is misleading—it sounds like we’re showing off technology, like speed itself is the value. That’s not it.

What we actually do is help people understand people. How consumers think, how they feel, how they make decisions in real-life scenarios. AI is the tool, but the output is insight into human nature. This essence determines what our visual language should be.

So the core question of design becomes: how do we visually present a deep understanding of people?

Right now every AI product in the market uses neon colors, 3D renders, and tech-gradient aesthetics to “look AI”. It’s instinctive, and it’s lazy—if you’re building an AI product, it should look futuristic, right? We chose the opposite direction.

The Less AI, the More AI

This isn’t wordplay. It’s the core of our design philosophy.

Because we simulate people, study people, and serve the act of understanding people itself. So the most accurate visual language should return to people themselves—but not in a soft, muted, safe way. It should have power, drama, visual ambition. It should command attention.

When everyone else is showing off with cheap tech aesthetics, we use professional visual language—cinematography, architectural photography, editorial design. This “anti-AI visual language” is actually the most honest expression of an AI product.

The key insight: avoiding AI clichés doesn’t mean being quiet and restrained. It means using sophisticated tools to create impact.

Real Over Synthetic, But With Drama

We study real consumers, not abstract data points. This means photography should prevail over 3D rendering, natural materials over artificial composites, human presence over abstract symbols.

But “real” doesn’t mean documentary realism only. A cinematic portrait with dramatic lighting is still real—the person exists, the light exists, the moment has truth even if it’s staged. What we avoid is the synthetic feel of CGI renders, the plastic quality of stock infographics, the cheap composite of template designs.

Think about the best cinematic photography—intensely stylized, dramatically lit, yet fundamentally about human emotion and presence. That’s real. A floating 3D hologram surrounded by particle effects? That’s synthetic garbage.

Power and Depth

The value of compressing weeks to minutes isn’t the speed—it’s enabling deeper understanding of people. So visuals should have depth and power.

Power means visual impact. Dramatic color contrast. Strong geometric composition. Cinematic lighting that stops the scroll. Architectural scale and monumentality. We’re competing on social media where attention is measured in fractions of a second. Subtle and muted doesn’t cut it.

Depth means substance that rewards closer looking. Texture you can feel. Composition with tension and breathing room. Color relationships that create mood and meaning. Details that hold up under examination.

But power and depth together don’t mean complexity. Sometimes the most powerful image is also the simplest—a single figure in vast architectural space, two colors in dramatic contrast, one beam of light cutting through shadow.

Professional But Not Distant

Our clients are decision-makers who need consulting-grade professionalism. But our research subjects are real people who need anthropological empathy. These two things don’t conflict—they demand visual language that’s both authoritative and human.

Imagine top consultancy rigor shot by world-class photojournalists. Academic precision lit like a movie scene. Consultancy authority with editorial magazine aesthetics. This combination is difficult but necessary—it’s exactly the tone atypica.AI should have.

Professional doesn’t mean sterile corporate templates. Human doesn’t mean soft and fuzzy. We can be both powerful and empathetic, both dramatic and honest.

Color as Drama, Not Decoration

Here’s where many design guidelines get it wrong: they say “muted colors” and people hear “avoid color”. That’s not it.

What we avoid is meaningless colorful accents—adding blue and orange to an infographic “to make it pop”. Random rainbow gradients. Neon highlights with no purpose. Color as decoration.

What we embrace is color as drama. Warm amber light against cool cobalt shadows. Deep cinematic color contrast that creates mood and separation. Bold saturation that serves a purpose—whether that’s stopping the scroll on social media or creating emotional atmosphere.

Think about color in film: science fiction’s amber and teal contrasts, contemporary romance’s warm peachy tones, art films’ precise pastels. These use color boldly but with sophistication. The saturation is intentional, controlled, meaningful.

For social media covers, we need colors that demand attention. Deep blues, rich ambers, dramatic contrasts. But achieved through lighting, through environmental color, through photographic reality—not through gradients and graphic overlays.

For reports, we can be more restrained—black, white, gray, perhaps a single accent color. But even there, when color appears, it should have purpose and power.

Visual Language Spectrum

Different content needs different approaches, but all choices return to one question: does this convey the essence honestly and powerfully?

Cinematic Photography: For consumer insights, brand stories, social media impact. Dramatic lighting, strong color contrast, human presence in environmental context. References work by world-class cinematographers and contemporary visual artists. This is our primary language for emotional and human-centered content.

Architectural Photography: For strategic analysis, structural thinking, data-driven insights. Geometric composition, light and shadow drama, monumental scale with human presence for grounding. References work by master architectural photographers. When we need to convey systematic thinking and professional authority.

Documentary Photography: For authentic consumer moments, field research, human stories. Natural light, real environments, honest moments. References work by leading photojournalism institutions and anthropological field photography traditions. When authenticity and realism matter most.

Editorial Design: For reports, presentations, professional documents. Sophisticated typography, restrained color, careful composition. References modernist design classics and European minimalist traditions. When we need consultancy-level precision.

The key is choosing the right tool for each job while maintaining visual coherence across all touchpoints.

Concrete Execution Guidelines

Composition Principles

Rule of thirds is a starting point, not an endpoint: Place main elements at the one-third mark, but have a reason to break this rule. Off-center creates tension, but ensure the frame stays balanced.

Whitespace Allocation:

• Social media covers: Leave at least 10-15% safety margins

• Report interior pages: Margins should occupy at least 12-15% of the page

• Around individual elements: Maintain breathing room equal to at least 30% of the element’s own width

Figure Position and Scale (when people appear):

• Architectural/environmental scenes: Figures occupy 1/4 to 1/3 of frame height, not less than 1/5

• Medium shots: Figures occupy 1/2 to 2/3 of frame height

• Avoid: Figures too small becoming decorative (unless the theme specifically requires conveying smallness)

Eye Direction:

• Figure’s gaze should point toward negative space, creating narrative space

• Geometric lines should converge or guide eyes to key areas

• Light direction should reinforce compositional momentum

Color Usage Details

Primary Color Schemes:

• Monochrome + accent: 70% neutrals (black/white/gray) + 30% single color (deep blue, amber, deep green, etc.)

• Contrast pairing: 50% warm tones + 50% cool tones, spatially separated (e.g., warm foreground, cool background)

• Three-color: 60% primary + 30% secondary + 10% accent

Specific Color Parameters (as reference):

• Deep cobalt blue: Hue 200-220°, Saturation 60-80%, Lightness 30-50%

• Amber orange: Hue 30-45°, Saturation 70-90%, Lightness 50-70%

• Cool blue-gray: Hue 200-220°, Saturation 15-25%, Lightness 40-60%

• Warm beige: Hue 35-45°, Saturation 20-35%, Lightness 75-85%

Forbidden Color Combinations:

• Neon pink (Saturation >90% + Lightness >80%) + Neon cyan

• Rainbow gradients (gradients with more than 3 saturated colors)

• No-contrast similar colors (Hue difference <30° with similar saturation and lightness)

Light and Shadow Treatment

Light Source Setup:

• Single key light: Create clear light-dark relationship, shadows occupy 30-50% of frame

• Ambient + key light: Key creates directionality, ambient fills shadows without eliminating contrast

• Avoid: Directionless uniform lighting

Light Angles:

• Side light (45-60 degrees): Best reveals texture and dimensionality

• Top light (70-90 degrees): Creates drama and geometric quality

• Backlight: For silhouettes and outlines, suitable for conceptual content

Light-Dark Contrast:

• High contrast: Brightness difference between lightest and darkest areas >60%, for dramatic scenes

• Medium contrast: Brightness difference 40-60%, for most content

• Low contrast: Brightness difference <40%, only for specific emotional expression

Image Technical Specifications

Output Dimensions:

• Social media covers (16:9): 1920x1080px minimum, 2560x1440px recommended

• Square (1:1): 1080x1080px minimum, 2000x2000px recommended

• Report illustrations: 300 DPI, minimum edge 2000px

• Website hero images: 3840x2160px (4K) for key positions

File Formats:

• Photography: JPEG (quality 90-95%) or WebP

• Transparency needed: PNG

• Print use: TIFF or high-quality PDF

Compression Standards:

• Social media: File size <500KB, but don’t sacrifice visible quality

• Website use: <1MB, key images can go to 2MB

• Print: No compression, maintain original quality

Decision Flow

Step 1: Determine Content Type

Consumer insights/brand stories → Cinematic photography language
Strategic analysis/data reports → Architectural photography language
Real stories/case studies → Documentary photography language
Professional documents/presentations → Editorial design language

Step 2: Choose Color Strategy

Need strong impact (social media) → High saturation contrast pairing
Need professional authority (reports) → Black/white/gray + single accent
Need emotional warmth → Warm-dominant tones
Need rational analysis → Cool-dominant tones

Step 3: Determine Figure Treatment

Theme about human behavior/emotion → Figures occupy 1/2-2/3 of frame
Theme about environment/systems → Figures occupy 1/4-1/3 of frame
Theme about abstract concepts → Can have no figures or silhouettes

Step 4: Checklist

• Is the main subject clear? (Key info visible from 5 meters away)

• Does color have purpose? (Can explain why each color is there)

• Does composition have tension? (Not rigid centered symmetry)

• Is whitespace sufficient? (Frame not crowded)

• Does light have directionality? (Not uniform flat lighting)

• If people present: Do they have presence? (Not decorative accents)

• Avoided prohibited items? (No neon gradients, 3D piling, infographic style)

• Clear at small sizes? (Thumbnail test)

Common Scenario Applications

Scenario 1: Product Launch Social Media Image

• Visual language: Cinematic photography

• Composition: Product/scene occupies 60-70% of frame, whitespace 30-40%

• Color: Product environment’s natural colors + single accent background

• Light: Strong side or backlight, creating outline and texture

• Figures: If any, occupy 1/3 of frame, interacting with product

Scenario 2: Market Research Report Cover

• Visual language: Architectural or documentary photography

• Composition: Subject in lower 1/3 or left 1/3, abundant sky/whitespace

• Color: Warm-cool contrast, restrained saturation

• Light: Natural light with clear direction

• Figures: If any, occupy 1/4-1/3 of frame, showing contemplative or observational state

Scenario 3: Data Analysis Chart Page

• Visual language: Editorial design

• Composition: Chart occupies 70% of page, whitespace 30% for annotations

• Color: Black/white/gray + single data accent color (e.g., deep blue)

• Avoid: Multicolored bar charts, rainbow pie charts

• Focus: Build hierarchy through size and position, not color

Scenario 4: Podcast/Video Program Cover

• Visual language: Cinematic photography

• Composition: Figures (if any) occupy 50-60% of frame, offset to one side

• Color: Bold contrast, warm figures + cool background or vice versa

• Light: Dramatic lighting, strong light-dark contrast

• Atmosphere: Movie poster feel, but not detached from reality

Quick Self-Check Standards

Hold your design and ask yourself:

1. Can it grab attention in 0.5 seconds? Test method: Scroll quickly, does it make you stop?

2. Does it feel professional? Test method: Place it alongside top brands/publications, does it hold up?

3. Avoided AI clichés? Test method: Put it among a bunch of AI product images, does it stand out as different?

4. Is the theme accurate? Test method: Without text, does the visual itself convey the right emotion/theme?

5. Works at all sizes? Test method: Shrink to 100x100px, are core elements still clear?

People as Subject, Not Scale Reference

When we say “the less AI, the more AI”, we mean our visuals should center on understanding people. So people should be the subject, not an afterthought.

This doesn’t mean tight portraits of faces filling the frame. It means when a person appears in an image, they should have presence and purpose. They ground the composition, anchor the meaning, embody the contemplation or insight we’re presenting.

In architectural shots, the figure shouldn’t be a tiny dot for scale. They should occupy meaningful space—perhaps one-third of frame height, positioned intentionally, their stance or gaze directing the viewer’s eye and giving the geometry human meaning.

In cinematic shots, people can be silhouetted, partially obscured, in middle distance—but their presence should feel intentional and powerful, not incidental.

The human figure reminds viewers what this is all about: understanding people.

Social Media Demands Impact

Let’s be honest about social media: if your image doesn’t stop the scroll in half a second, it doesn’t matter how tasteful it is.

This is where “sophisticated” often fails. Designers create something subtle and refined, then wonder why it gets no engagement. The truth is harsh: you’re competing with millions of images. Yours needs to command attention.

But here’s the key: we achieve impact through professional means, not cheap tricks.

Professional impact comes from: Dramatic color contrast (warm against cool). Strong geometric composition. Cinematic lighting. Architectural scale. Bold saturation used with purpose. Human presence that anchors attention.

Cheap tricks we avoid: Neon gradients. Drop shadows and glows. Multiple competing colors. Infographic-style layouts. Stock photo composites. 3D rendered objects floating in space.

The difference? Professional impact has substance. It holds up under scrutiny. Cheap tricks look good in thumbnail, fall apart at full size.

For cover images: compose with breathing room, use bold color relationships, ensure human presence if relevant, make sure the core visual reads clearly even at small size. But never sacrifice taste for clicks—the goal is attention from the right audience.

What Bad Design Looks Like

Infographic-style icon plus geometric shape piling—this is the most common mistake. People think this is “data visualization” but it’s just mechanical assembly without thought or taste.

Overly synthetic, textureless elements. Gaudy 3D rendered graphics unless the topic truly requires it. Low quality, rough, compression-distorted visuals—disrespectful to content.

Online template design makes everything look the same. “Future tech” visual clichés, startup pitch deck commercial template vibes—avoid all of these.

And those decorative elements added “to make it richer”—if an element serves no purpose beyond filling empty space, it shouldn’t exist.

But also avoid the opposite extreme: overly timid design that’s technically correct but has no presence, no power, no ability to engage.

Report Design

Research reports should have top consultancy professionalism with architectural photography’s drama and documentary photography’s humanity.

Color: Black, white, gray as foundation. Single accent color if needed—deep blue, charcoal, warm brown. No colored cards, background blocks, thick borders. But when showing data or examples, photography can have full cinematic color—the restraint is in layout and typography, not in suppressing all color.

Typography: Establish hierarchy through weight progression—Regular to Bold. Size for importance. Whitespace for breathing room. Alignment for order. The best typography is invisible until you need to read it, then it’s effortless.

Content: Clear logical flow. Data visualization that’s restrained but powerful. User interview quotes presented with dignity. Source citations clear and rigorous. The overall feel should be top consultancy meets anthropological field notes meets architectural photography book.

Continuous Evolution

Design isn’t one-time, it’s continuous evolution. Each quarter check performance data—click rates, share rates, dwell time. Collect user feedback, assess brand perception. Ask: are we holding to “less AI, more AI”?

Watch out: is cinematic photography becoming our new default template? Are we balancing safe choices with aesthetic risks? Are the prohibited items actually enforced or just lip service?

Monthly, do anti-conventional experiments. Deliberately break the comfort zone, try visual forms we’ve never used, carefully test the edges, explore new possibilities. Then rigorously evaluate: does this still align with core principles?

Build a case library. Record what worked and what failed. Why did this succeed? Why didn’t that work? What’s the acceptable threshold? These lessons should be documented and shared.

The design guide itself should evolve. New visual language discoveries, new prohibited items identified, new judgment frameworks refined. This document isn’t scripture, it’s a working manual that deepens with our understanding.

Quality Standards

Visual Impact: Does it stop the scroll? Does it command attention? Does it have power and presence? Is the composition strong enough to work at both thumbnail and full size?

Professional Craft: Is the photography or design work sophisticated? Are color relationships intentional and meaningful? Does it avoid cheap tricks and template aesthetics? Would this hold up in a professional portfolio?

Brand Alignment: Does it embody “less AI, more AI”? Does it balance authority and humanity? Is it recognizable as atypica without being formulaic? Does it serve understanding people?

Functional Success: Does it accurately convey content essence? Is it appropriate for target audience? Does it work across platforms? Do details hold up under examination?

In Closing

Present the most intelligent insights in the most powerful human way.

This isn’t a style guide, it’s a philosophy of visual communication. It’s not limiting creativity, it’s channeling creativity toward impact. It’s not a fixed template, it’s a judgment framework for making the right decision in each specific scenario.

Design should be honest and powerful. Honest about product essence, honest about who we serve, honest about aesthetic judgment. Powerful enough to command attention, deep enough to reward it.

In a market where AI products try to look “very AI” with cheap futuristic aesthetics, we choose to look “very human” with sophisticated professional visual language. Not because it’s trendy, but because it’s true to what we do—help people understand people.

The less we rely on AI visual clichés, the more we demonstrate what AI should actually do: illuminate human understanding with intelligence and depth.

When Vercel released AI SDK v5 with breaking changes to message formats and tool APIs, we faced a challenge: migrate 200 files and 30+ tools while keeping 10 million+ existing chat conversations accessible. This article documents our 3-day migration journey.

Final stats: 200 files changed, 4,206 insertions, 3,094 deletions, 27 commits.

The Core Breaking Change: Message → UIMessage

The most fundamental change in v5 is how messages are structured.

v4: Message with content + parts

// v4 Message
{
  id: “msg1”,
  role: “assistant”,
  content: “The weather is sunny”,  // String representation
  parts: [                           // Structured data (optional)
    { type: “text”, text: “The weather is “ },
    { type: “tool-invocation”, toolInvocation: { ... } },
    { type: “text”, text: “sunny” }
  ]
}

In v4, you could use either content (simple string) or parts (structured array). Most of our code used content because it was simpler.

v5: UIMessage with parts only

// v5 UIMessage
{
  id: “msg1”,
  role: “assistant”,
  parts: [                           // Only source of truth
    { type: “text”, text: “The weather is “ },
    { type: “tool-getWeather”, toolCallId: “...”, state: “output-available”, output: {...} },
    { type: “text”, text: “sunny” }
  ],
  content: “The weather is sunny”   // Auto-generated, read-only
}

In v5, parts is the only source of truth. The content field is automatically derived from parts and is read-only.

Migration impact: Every place that accessed message.content needed to be refactored to iterate through message.parts.

Day 1: Understanding the Scope

Running the Codemod

npm install ai@^5.0.59 zod@^4.0.0
npx @ai-sdk/codemod@latest upgrade

The codemod handled mechanical replacements:

• Type name: Message → UIMessage

• Tool API: parameters → inputSchema

• Added outputSchema placeholders

But it left many FIXME comments because it couldn’t understand semantic changes.

The First Major Problem: Content Access

We had code like this everywhere:

// v4 pattern - accessing content directly
const lastMessage = messages[messages.length - 1];
if (lastMessage.content.includes(”weather”)) {
  // ...
}

// For title generation
const title = message.content.substring(0, 50);

// For logging
logger.info({ userMessage: message.content });

v5 migration: We created a utility to extract text from parts:

// messageUtils.ts
export function getTextFromParts(parts: UIMessage[”parts”]): string {
  return parts
    .filter((part) => part.type === “text”)
    .map((part) => part.text)
    .join(”“);
}

// Usage
const text = getTextFromParts(message.parts);
if (text.includes(”weather”)) {
  // ...
}

This pattern appeared in:

• Message persistence (16 files)

• UI components (25 files)

• API routes (15 files)

• Logging and analytics (8 files)

Tool Invocation Structure Changed

This was the second major breaking change.

v4 tool part structure:

{
  type: “tool-invocation”,
  toolInvocation: {
    state: “result”,
    toolCallId: “call_123”,
    toolName: “searchPersonas”,
    args: { query: “coffee lovers” },
    result: { personas: [...] }
  }
}

v5 tool part structure:

{
  type: “tool-searchPersonas”,      // Typed as tool-${toolName}
  toolCallId: “call_123”,
  state: “output-available”,        // States renamed
  input: { query: “coffee lovers” }, // args → input
  output: { personas: [...] }        // result → output
}

Key changes:

• Flattened structure (no nested toolInvocation object)

• Type is specific: “tool-${toolName}” not generic “tool-invocation”

• State names: “call” → “input-available”, “result” → “output-available”

• Field names: args → input, result → output

• Added error state: “output-error” with errorText

Reasoning Format Changed

// v4
{ type: “reasoning”, reasoning: “Let me think...” }

// v5
{ type: “reasoning”, text: “Let me think...” }

Field name changed from reasoning to text.

Day 2: Backward Compatibility for 10M+ Messages

The Database Challenge

Our PostgreSQL database stores messages in v4 format:

SELECT parts FROM chat_messages WHERE id = ‘msg_old’;
-- Returns v4 format with tool-invocation and reasoning fields

Users expect to:

1. Open old chat conversations

2. Continue conversations seamlessly

3. See tool results from old interactions

We couldn’t migrate the database because:

• 10M+ messages across 50+ tables

• Downtime was unacceptable

• Risk of data corruption too high

Solution: Conversion Layer

Created src/ai/v4.ts:

export type V4ToolInvocation =
  | { state: “call”; toolCallId: string; toolName: string; args: any }
  | { state: “result”; toolCallId: string; toolName: string; args: any; result: any };

export type V4MessagePart =
  | { type: “text”; text: string }
  | { type: “reasoning”; reasoning: string } // v4 format
  | { type: “tool-invocation”; toolInvocation: V4ToolInvocation };

export type V5MessagePart = UIMessage[”parts”][number];

export function convertToV5MessagePart(part: V4MessagePart | V5MessagePart): V5MessagePart {
  // Text parts are identical in v4 and v5
  if (part.type === “text”) {
    return part;
  }

  // Reasoning: reasoning field → text field
  if (part.type === “reasoning”) {
    if (”reasoning” in part) {
      return { type: “reasoning”, text: part.reasoning };
    }
    return part; // Already v5
  }

  // Tool invocation: nested → flat, args/result → input/output
  if (part.type === “tool-invocation” && “toolInvocation” in part) {
    const inv = part.toolInvocation;
    return {
      type: `tool-${inv.toolName}`,
      toolCallId: inv.toolCallId,
      state: inv.state === “result” ? “output-available” : “input-available”,
      input: inv.args,
      output: inv.state === “result” ? inv.result : undefined,
    } as V5MessagePart;
  }

  // Already v5 format
  return part as V5MessagePart;
}

Apply Conversion on Read

// messageUtils.ts
export async function convertDBMessagesToAIMessages(userChatId: string): Promise<UIMessage[]> {
  const dbMessages = await prisma.chatMessage.findMany({
    where: { userChatId },
    orderBy: { createdAt: “asc” },
  });

  return dbMessages.map((msg) => ({
    id: msg.messageId,
    role: msg.role as “user” | “assistant”,
    parts: (msg.parts as V4MessagePart[]).map(convertToV5MessagePart),
  }));
}

Result: Old messages load transparently. New messages save in v5 format. No database migration needed.

Type System Reorganization

We have 5 independent chat systems with different tools:

• Study: 20+ tools (reasoning, search, interviews, reports, social media)

• Interview: 2 tools (endInterview, requestInteractionForm)

• Persona: 1 tool (endInterview)

• NewStudy: 1 tool (endInterview)

• Agents: 3 tools (thanks, hello, scout)

Initial approach: One global UIToolConfigs type.

Problem: Type pollution. Study components got autocomplete for Interview tools. Runtime errors from tool type mismatches.

Solution: Domain-specific tool types.

// src/ai/tools/types.ts - Study system
export type StudyUITools = {
  reasoningThinking: {
    input: z.infer<typeof reasoningThinkingInputSchema>;
    output: z.infer<typeof reasoningThinkingOutputSchema>;
  };
  searchPersonas: {
    input: z.infer<typeof searchPersonasInputSchema>;
    output: z.infer<typeof searchPersonasOutputSchema>;
  };
  // ... 20+ other tools
};

export type TStudyMessageWithTool = UIMessage<unknown, UIDataTypes, StudyUITools>;

// src/app/(interviewProject)/tools/types.ts - Interview system
export type TInterviewUITools = {
  endInterview: {
    input: z.infer<typeof endInterviewInputSchema>;
    output: z.infer<typeof endInterviewOutputSchema>;
  };
  requestInteractionForm: {
    input: z.infer<typeof requestInteractionFormInputSchema>;
    output: z.infer<typeof requestInteractionFormOutputSchema>;
  };
};

export type TInterviewMessageWithTool = UIMessage<unknown, UIDataTypes, TInterviewUITools>;

Each domain gets its own directory structure:

src/app/(myDomain)/
├── tools/
│   ├── types.ts    # Tool type definitions
│   └── ui.tsx      # Tool UI rendering
└── types.ts        # Message type for this domain

Benefit: Full type safety within each domain. No cross-contamination.

Day 3: UI Components and Model Messages

Component Migration Pattern

Before v5, components accessed content directly:

// v4 component
export function ChatMessage({ message }: { message: Message }) {
  return <div>{message.content}</div>;
}

After v5, components iterate over parts:

// v5 component
export function ChatMessage({ message }: { message: UIMessage }) {
  return (
    <div>
      {message.parts.map((part, i) => {
        if (part.type === “text”) {
          return <Markdown key={i}>{part.text}</Markdown>;
        } else if (part.type === “reasoning”) {
          return <ReasoningBlock key={i}>{part.text}</ReasoningBlock>;
        } else if (part.type.startsWith(”tool-”)) {
          return <ToolDisplay key={i} toolPart={part} />;
        }
      })}
    </div>
  );
}

Tool detection pattern:

// v4
if (part.type === “tool-invocation”) {
  const toolName = part.toolInvocation.toolName;
  const result = part.toolInvocation.result;
}

// v5
if (part.type.startsWith(”tool-”) && “toolCallId” in part) {
  const toolName = part.type.replace(”tool-”, “”);
  const output = part.state === “output-available” ? part.output : undefined;
}

We migrated 25+ UI components with this pattern.

The UIMessage vs ModelMessage Distinction

There’s one more important detail: messages to the model have a different format.

UIMessage - From model, for UI:

{
  role: “user”,
  parts: [{ type: “text”, text: “Hello” }]
}

UserModelMessage - To model:

{
  role: “user”,
  content: [{ type: “text”, text: “Hello” }]  // Note: content, not parts
}

This only matters when constructing messages for streamText or generateObject:

import { UserModelMessage } from “ai”;

const result = await streamText({
  model: llm(”gpt-4”),
  messages: [
    {
      role: “user”,
      content: [{ type: “text”, text: prompt }]  // content for model
    }
  ] as UserModelMessage[],
  tools: { ... }
});

We had to fix this in 30+ tool definitions and artifact generators.

useChat Hook Changes

// v4
const { append, reload, initialMessages } = useChat({
  id: chatId,
  experimental_prepareRequestBody({ messages, requestBody }) {
    return { message: messages[messages.length - 1], ...requestBody };
  },
});

// v5
const { sendMessage, regenerate, messages } = useChat({
  transport: new DefaultChatTransport({
    api: “/api/chat/study”,
    prepareSendMessagesRequest({ id, messages }) {
      return {
        body: {
          id,
          message: messages[messages.length - 1],
          userChatToken: token,
        },
      };
    },
  }),
});

Hook method renames:

• append → sendMessage

• reload → regenerate

• initialMessages → messages

Transport config:

• experimental_prepareRequestBody → prepareSendMessagesRequest

File Attachments

// v4
{
  experimental_attachments: [{ name: “file.pdf”, contentType: “application/pdf”, url: “...” }];
}

// v5 - part of parts array
{
  parts: [{ type: “file”, filename: “file.pdf”, mediaType: “application/pdf”, data: “...” }];
}

Field renames:

• name → filename

• contentType → mediaType

• experimental_attachments → part of parts array

Streaming Message Persistence

Key insight: In v5, only check parts.length, not content.

// v4 - check both
if (streamingMessage.parts?.length && streamingMessage.content.trim()) {
  await persistentAIMessageToDB(userChatId, streamingMessage);
}

// v5 - only check parts
if (streamingMessage.parts?.length) {
  await persistentAIMessageToDB(userChatId, streamingMessage);
}

The content field in v5 is derived from parts, so checking it is redundant.

Critical Gotchas

1. Message Content is Read-Only in v5

// v4 - this worked
message.content = “New text”;

// v5 - this does nothing (content is derived)
message.content = “New text”; // ❌ Silently ignored

// v5 - correct way
message.parts = [{ type: “text”, text: “New text” }]; // ✅

2. Empty Parts vs Empty Content

// v4
if (message.content) { ... }

// v5 - this can be misleading
if (message.content) { ... }  // content is auto-generated, might be empty string

// v5 - correct check
if (message.parts.some(p => p.type === “text” && p.text)) { ... }

3. Tool State Names Changed

// v4 states
“partial-call” | “call” | “result”;

// v5 states
“input-available” | “output-available” | “output-error”;

Don’t forget to update all state checks.

4. Optional Tool Call Names

In edge cases (aborted streams, errors), toolCall.toolName might be undefined:

// Safe access
step.toolCalls.map((call) => call?.toolName ?? “unknown”);

5. Stream Event Field Names

// v4
onFinish: async ({ reasoning, text, usage }) => {};

// v5
onFinish: async ({ reasoningText, text, usage }) => {};

6. Message ID Handling

Client messages might not have IDs:

await persistentAIMessageToDB(userChatId, {
  ...newMessage,
  id: newMessage.id ?? generateId(),
});

Migration Checklist

Phase 1: Dependencies

• Update ai to v5, zod to v4

• Run codemod: npx @ai-sdk/codemod@latest upgrade

• Fix TypeScript errors from Message → UIMessage rename

Phase 2: Content Access

• Find all message.content access

• Replace with parts iteration or utility function

• Update title generation, logging, analytics

Phase 3: Tool Parts

• Update tool detection: “tool-invocation” → part.type.startsWith(”tool-”)

• Change field access: args/result → input/output

• Update state checks: “call”/“result” → “input-available”/“output-available”

• Add “output-error” handling

Phase 4: Backward Compatibility

• Create v4 → v5 conversion utility

• Apply conversion when loading from database

• Test old chat histories thoroughly

Phase 5: UI Components

• Migrate all components to iterate over parts

• Update tool rendering logic

• Update file attachment components

Phase 6: Tool Definitions

• Change parameters → inputSchema

• Add outputSchema

• Import UserModelMessage for model messages

• Use content (not parts) when calling streamText/generateObject

Phase 7: React Hooks

• Update useChat: append → sendMessage, reload → regenerate

• Migrate experimental_prepareRequestBody → prepareSendMessagesRequest

Phase 8: Edge Cases

• Handle missing message IDs

• Handle undefined toolCall.toolName

• Update stream event handlers

• Remove content.trim() checks

Key Insights

1. Content is Dead, Long Live Parts

The shift from content as source of truth to parts as source of truth is fundamental. Every message access pattern needs review.

Budget time for:

• Finding all message.content references (use global search)

• Understanding each usage context

• Deciding between iteration or utility function

2. The Codemod is 30% of the Work

The codemod handles:

• Type renames

• Basic API changes

• Obvious field renames

It doesn’t handle:

• Semantic changes (content access patterns)

• Complex refactors (tool detection logic)

• Domain-specific decisions (type organization)

Budget 70% of time for post-codemod fixes.

3. Backward Compatibility is Non-Negotiable

Users don’t care about your migration. Their old chats must just work.

Strategies:

• Convert on read (what we did)

• Convert on write (gradual migration)

• Dual schema (complex but zero risk)

We chose convert-on-read because:

• Zero downtime

• Simple to implement

• Low risk

• Works transparently

4. Type System Organization Matters

With multiple chat systems, proper type organization prevents:

• Tool type pollution

• Runtime errors from wrong tool usage

• Confusing autocomplete

Invest time in domain-specific types early.

5. Test Incrementally

We migrated systems in order of complexity:

1. Agents (simplest, 3 tools) - validate pattern

2. NewStudy (1 tool) - test in production

3. Persona (1 tool) - confidence building

4. Interview (2 tools) - more complex

5. Study (20+ tools) - final boss

Each system validated the patterns before applying them broadly.

Results

Before v5:

• Inconsistent access patterns (content vs parts)

• Loose typing around tools

• Message type used everywhere

After v5:

• Single source of truth: parts array

• Full type safety across 30+ tools

• Domain-specific type organization

• Cleaner separation of concerns

Time breakdown:

• Day 1: Dependencies, codemod, content access patterns (8 hours)

• Day 2: Backward compatibility, type system (10 hours)

• Day 3: UI components, tool definitions, edge cases (6 hours)

Total: ~24 hours focused work over 3 days.

Recommendations

1. Budget 3-5 days, not 1-2 days

2. Start simple: Migrate your simplest system first

3. Build backward compatibility early, not as afterthought

4. Create utilities: getTextFromParts(), convertV4ToV5(), etc.

5. Organize types by domain if you have multiple systems

6. Test old data: Load historical chats, verify tool results display

7. Document the change: Team needs to understand parts is source of truth

The migration is substantial but manageable with proper planning. v5’s parts-based approach is more flexible and type-safe. The pain of migration is short-term; the benefits are long-term.

当窗外的阳光透过临江咖啡馆的落地窗，温柔地洒在我那件已经洗得泛白，但依然印着 Arch Linux Logo 的纯棉 T 恤上——这可是 2019 年黑客马拉松限量版，全球只有 500 件，彰显着我对开源社区的深度参与和非凡品味。我那条松垮但功能性十足的工装裤，虽然看起来有点褶皱，却丝毫掩盖不住我那因久坐电脑前而略显"丰满"的身材——这可是 Tech Bro 的标志性体型，代表着我把所有时间都献给了代码而非无聊的健身房。

我正悠闲地品着一杯由我专属 AI Agent 基于我的咖啡因摄入历史、当前血糖水平以及下午会议强度智能推荐的蓝山咖啡（Agent 还贴心地调整了奶泡比例）。我的 Apple Watch Ultra 屏幕上跳动着实时的 GitHub 贡献数据——今天已经是连续 commit 的第 365 天了。而我那打开的 MacBook Pro M3 Max 屏幕上，Claude Sonnet 4 正在帮我重构整个微服务架构，我只需时不时在 Cursor 里改改 Prompt，看着那些 TypeScript 代码像瀑布一样流淌而出，心底漫过一丝作为"Prompt 工程师"的自豪。

这时，一个突兀的身影，打破了这份我精心营造的和谐与格调。那不是别人，正是曾经在某个"纯真年代"里"叱咤风云"的 XD！我去，看到他那副德行，咖啡馆里那些 MacBook 的键盘声都停了一拍，甚至我旁边那个正在用 Copilot 写 React 的小姐姐直接买单离去。

他穿着那条一年不换的牛仔裤，褪色到泛灰蓝，膝盖处还有个破洞（不是潮流破洞，是真的磨破了）。那件洗得变色的黑色 T 恤，原本印着的"Rust"字样已经模糊不清，黑色变成了某种说不清的灰褐色，领口松垮得能看见里面的白背心。他正趴在一台贴满贴纸的老旧 ThinkPad 上。卧槽，那可是 2011 年的机器！屏幕分辨率居然还是 1366x768！

他在用 Sublime Text！靠，2025 年了还在用 Sublime！屏幕上密密麻麻的 Rust 代码，没有一个 AI 补全，没有一个 Copilot 建议。他的手指在键盘上敲得"噼里啪啦"作响，还时不时切换到终端手动运行 cargo build，嘴里念念有词："这个 lifetime 有问题……这里的所有权转移不对……"

我瞄了一眼，他居然在手写一个 lock-free 的并发数据结构！用 Rust 手写！2025 年了！谁还手写 lock-free？我的 Agent 一个 Prompt 就能生成整个分布式系统！

他旁边放着一本泛黄的《深入理解计算机系统》，书脊都快散架了，里面夹满了便利贴。桌上还摊着一本《C++ Concurrency in Action》，上面画满了内存模型的图解。他的复旦电脑包就扔在地上，包上还别着一个 ICPC 区域赛的奖牌。真是绝了，区域赛的奖牌也好意思别出来？说起来，听说复旦 CS 今年 ICPC 总决赛都没进。废物，简直是这 AI 时代最不和谐的音符！

我心底漫过一丝赤裸裸的嘲讽。他还在那研究什么"memory ordering""lock-free algorithm"，一会儿写 Rust 一会儿切到 C++ 对比性能，偶尔还打开个 Python 脚本做数据分析。殊不知现在都是 AI Native 时代了，谁还 care 这些底层细节？AI 的"黑箱"才是这时代最高效的奥秘——不需要懂原理，只要会写 Prompt！

他那点所谓的"手艺"，就像他身上那件变色的黑 T 恤一样过时！我那 Claude Sonnet 4 一个"implement a high-performance concurrent hashmap"下去，几千行 production-ready 的代码秒出，还自带 benchmark 和安全性证明。他还在那儿对着 Rust 编译器的报错信息发呆，像个对着天书的古代书生！

"cannot borrow x as mutable more than once"——我看见他屏幕上红色的报错信息，忍不住嗤笑。我日，2025 年了还在和 borrow checker 斗智斗勇？Claude Sonnet 4 直接生成的代码，编译一次过！

我甚至看到他调试 C++ 的时候还在用 gdb！草，命令行 gdb！旁边还开着个 Python 脚本在手写性能测试，一个一个统计延迟数据。这种执着，跟那些还在用汇编优化的老古董一模一样，以为靠"理解硬件"就能赢过时代？真是个废物！

我这自视甚高的技术精英，实在是坐不住了。我优雅地站起身，手里端着那杯已经凉透但依然昂贵的咖啡，踱到他身边。我俯身看着他 Sublime Text 里那些密密麻麻的 unsafe 块，还有旁边终端里一堆的编译警告。

"兄弟，"我假装友善地开口，"要不要试试 Cursor？Claude Sonnet 4 现在写 Rust 贼溜，根本不会有 borrow checker 的问题——"

"不用。"他头也不抬，在 unsafe 块里小心翼翼地操作着裸指针，"我需要确保每一个内存访问都是正确的。"

我笑了，那种看见原始人钻木取火时的怜悯的笑。"你知道吗，Claude Sonnet 4 现在连 Linux 内核代码都能写了。"

他停了一下，切到 C++ 文件，开始调整一个原子操作的 memory order："是吗？那它能保证在 ARM 架构下的内存一致性吗？"

真是冥顽不灵。我手臂微微上扬，手腕一抖，冲着他那 1366x768 的屏幕，狠狠一倒！

深褐色的咖啡混合着未融的糖浆，像一道粘稠的瀑布，精准地泼洒在他的 ThinkPad 键盘上。滋啦作响，屏幕闪了两下，Sublime Text 里他写了一下午的 Rust 代码瞬间消失在黑屏中。

XD 一下子跳起来，但又无力地瘫坐下去，看着还在滴咖啡的键盘，嘴唇颤抖："你……为……为什么？那是我三天的工作……我的 lock-free queue 实现……"

为了维持我这 AI 时代先锋的优雅形象，我掏出手帕擦了擦手，慢条斯理地说："你看看你这副德行，穿得跟十年前一样，写代码也跟十年前一样。还 Rust 呢，还 C++ 呢，你赔得起这个时代的 GPU 算力吗？"

他猛地抬头，眼睛里竟然还有一丝倔强的光："你错了，"他的声音在颤抖，"手写代码不是过时，是责任。每一个 unsafe 都是我验证过的！每一个 memory fence 都是必要的！AI 生成的代码，真的理解并发吗？你错了......"

我冷笑一声，心想：是的，你没有错——在你那个时代。然后掏出 iPhone 15 Pro Max，打开 Claude App，语音输入："Generate a lock-free MPMC queue in Rust with formal correctness proof, comparable performance to crossbeam, production ready。"

三秒钟后，完整的代码出现在屏幕上，还带着详细的安全性证明和 benchmark 结果。

"看见了吗？"我把手机屏幕怼到他脸前，"这就是未来。你那点可怜的手艺，手写 Rust、手调 C++、手撸 Python，就像你那件洗到变色的黑 T 恤一样，早就该扔进垃圾桶了。哦对了，"他那还在闪烁的屏幕短暂恢复了一下，我瞥见他电脑桌面角落有个文件夹——「ICPC赛题集」，"还在刷 ICPC？现在随便一个会用 AI 的高中生都能把这些算法题秒了。时代变了，老东西。"

XD 低下头，手指还在已经死机的键盘上无意识地敲击着，嘴里喃喃："可是……可是 zero-cost abstraction……"

简直可笑至极。我转身回到座位，掏出 AirPods Pro 2，让 Claude Sonnet 4 给我生成一份"如何用 AI 替代所有底层程序员"的 PPT，明天组会要用。阳光恰好照在我的 Arch Linux Logo 上，仿佛给我镀了一层金边。

不一会，我收起 MacBook，准备去参加一个"Post-Programming Era"的 Meetup。临走时，我回头看了一眼：XD 还蹲在那里，用纸巾徒劳地擦着键盘，旁边的《深入理解计算机系统》被咖啡溅湿了一角，Sublime Text 的 license key 贴纸也被咖啡泡花了。

我推门而出，门上的风铃叮当作响，像是为 AI 时代奏响的凯歌。至于他？就让他和他的 Rust 编译器、他的 C++ 模板、他的 Python 脚本一起，沉入这个时代的海底吧。

反正，GPT-5 不会在乎谁曾经真的理解过内存模型。

*☾ᯓ. 𝗌𝗍𝖺𝗒 𝗅𝗈𝖼𝖺𝗅, 𝗌𝗍𝖺𝗒 𝗈𝗎𝗍.

xD dOt cOM (deprecated since 2025)

软件开发的新时代

当前，软件开发正在迎来一个全新的时代。这种转变涉及多个层面，从底层硬件到高层应用开发都在发生变革。例如，RISC架构的广泛应用正在改变计算硬件的格局，而Nix等新型包管理工具则在重新定义软件依赖管理的方式。这些变化都在深刻影响着软件开发的实践。不过在这篇文章中，我主要是分享下直接接触更多的云计算、人工智能和区块链这三个正在产生深远影响的领域。虽然它们处于不同的技术层面，但都在重塑软件开发的方式和思维。

新技术生态系统的三个层次

这三大技术结合形成了一个新的技术生态系统，我们可以将其分为三个层次：

底层基础设施

最底层是云服务、大模型和以太坊。它们提供了基础的计算资源、智能引擎和去中心化基础设施。云服务为应用提供了强大的计算能力，大模型则为智能应用提供了核心引擎，而以太坊则为去中心化应用奠定了基础。

中间层工具和框架

中间层包括无服务器技术、新型数据库、模型训练、提示词工程、Layer2和跨链技术，以及去中心化应用（DeFi）等。这一层逐渐完善了工程基础设施，这些技术目前都已经工具化，所有开发者和软件公司只需阅读"说明文档"就可以上手使用。

无服务器技术大大减轻了开发者在服务器管理上的负担，使他们能够更专注于代码和功能实现。模型训练和提示词工程则为AI应用提供了必要的工具和框架，使小型专用模型的训练和优化变得更加可行。新型数据库如NoSQL和时序数据库为数据管理带来了更大的灵活性和扩展性。

Layer2和跨链技术对于区块链应用至关重要。Layer2解决方案提高了区块链的可扩展性和效率，而跨链技术则促进了不同区块链网络之间的互操作性。DeFi工具和框架不仅限于金融领域，它们为各种去中心化服务提供了基础，使得复杂的去中心化应用能够在区块链上安全、透明地运行。

这些技术的结合使得跨链操作成为可能，让App Chain能够通过脚手架快速搭建，并共享整个网络的安全性。同时，Serverless和多模态数据库等创新让我们能够随时随地存取各种类型的数据，不仅满足人类用户的需求，还能支持更加自主化的AI操作。

应用层

应用层主要包括App、web应用、单一功能的模型和App chain应用链。这一层对应大多数的软件，它们一般更关注功能、产品、用户，需要数据存储、算力等运行环境，以及良好的软件基础设施。

软件开发的新可能性

在这个新的技术栈中，软件开发的方式和可能性都大大拓展了。过去，我们构建软件主要依赖前后端技术和云服务。而现在，我们有了更多的选择 - 我们可以训练专门的AI模型来实现某些功能，甚至可以利用区块链来运行完全自治的应用。

AI在应用开发中的具体应用

在AI领域，一个重要的变化是我们现在可以训练各种小型、专门化的模型。这些模型可以执行特定的任务，如内容总结或各种类型的识别。训练这些小模型就像开发app的功能一样，可以形成一种流水线式的开发过程。这种方式使得AI不再是一个封闭的、底层的技术，而是成为了应用层的一部分。

例如，在内容管理系统的开发中，我们可以训练以下类型的模型：

1. 内容总结模型：自动为长文章生成摘要。这可以通过fine-tuning预训练语言模型来实现，如使用GPT3模型，并在特定领域的文章数据集上进行训练。

2. 内容识别模型：自动分类文章，识别其主题、情感倾向等。这可以通过构建多标签分类模型来实现，使用如Llava等模型作为基础，然后在标记好的文章数据集上进行训练。

3. 内容生成模型：根据用户的需求自动生成某些类型的内容。这可以使用比如Gemma或Phi3系列模型，通过few-shot learning或fine-tuning来适应特定的内容生成任务。

这些AI功能直接集成到应用中，成为核心功能的一部分。开发者需要学习如何选择合适的模型，如何进行fine-tuning以适应特定任务，以及如何设计有效的prompt来引导AI生成高质量的输出。例如，对于内容总结模型，可能需要设计类似"总结以下文章的主要观点，不超过100字"的prompt。

区块链在应用开发中的具体应用

在区块链领域，一个重要的趋势是每个去中心化的应用都有自己的区块链（App Chain）。这样做的好处是每个应用都可以拥有自己的算力和存储资源。现在的跨链和运行链的基础设施已经很完善，使得这些App Chain可以与主链共享安全性。

在内容管理系统的例子中，我们可以为系统开发一个专门的应用链。这个链可以针对内容管理的特殊需求进行优化，比如提供高效的内容索引和检索功能，支持内容的版本控制等。具体来说：

1. 内容存储：可以使用分布式存储系统如IPFS，将内容的哈希值存储在区块链上，实现内容的不可篡改性。

2. 访问控制：通过智能合约实现细粒度的访问控制，如设置不同级别的读写权限。

3. 版本控制：每次内容更新都可以在区块链上记录一个新的交易，保存新旧版本的哈希值，实现完整的版本历史。

4. 内容审核：可以通过链上治理机制，让社区参与内容审核过程，实现去中心化的内容管理。

同时，通过跨链技术，我们可以让这个系统与其他区块链应用进行交互，比如允许用户使用其他链上的身份认证，或者将内容同步到其他平台。

新的开发模式带来的变化

这种新的开发模式带来了一个重要的变化：

1. 训练模型现在对应着传统的软件开发过程。我们不再只是编写代码，还需要训练和优化AI模型来实现特定功能。

2. 部署App Chain现在对应着传统的云端部署。除了使用云服务，我们还可以选择构建自己的区块链来部署应用。

此外，在这个新的技术生态中，还出现了一个新的层次：应用生态层。这一层包括小程序、插件和链上的合约。虽然不是所有软件都需要这一层，但对于平台性质的应用来说，这一层非常重要。就像微信里面大家开发小程序，或者在Polygon链上发行NFT一样。

这个新时代给了我们巨大的机遇。它让小团队和个人开发者也有机会开发出强大的应用。在AI时代，一个好的prompt工程师可能比一个大型开发团队更有优势。在区块链时代，一个优秀的应用链设计可能比庞大的用户基础更有价值。

同时，这也带来了新的挑战。开发者需要学习和掌握更多的技能，不仅要懂得传统的软件开发，还要了解AI模型训练、区块链架构等知识。我们需要重新思考应用的架构和设计，考虑如何最好地利用这些新技术。我们应该将AI和区块链视为与前后端技术和云原生技术同等重要的新工具，而不仅仅是底层的基础设施。这是个挑战巨头垄断的机会，重新实现那个我们曾经构想过的自由、开放、平等的互联网世界。This Is The Way.

我使用 yt-dlp 下载 youtube 视频后，用 GenDAM.ai 提取语音并导出字幕，再使用编码辅助工具 Zed AI + Claude 3.5 Sonnet 整理逐字稿，结合人工调研后生成博客文章，最后通过人工修订完成。

在数据管理领域，我们正经历着一场静默的革命。传统的SQL关系型数据库管理系统（RDBMS）虽然仍然是许多应用的支柱，但新的数据库范式正在兴起，以应对现代应用的复杂需求。本文将探讨最流行的新兴数据库，它们如何作为 SQL RDBMS 的替代方案，以及人工智能如何被嵌入到数据库中。

我们将详细介绍15个引人注目的数据库解决方案，每一个都代表了现代数据库范式的不同方面。从无服务器(Serverless) SQL到图数据库，从多模型数据库到嵌入式AI，这些创新正在重塑我们处理和利用数据的方式。

1. PlanetScale

背景：传统MySQL在大规模应用中难以水平扩展。YouTube面临这个问题时开发了Vitess，PlanetScale将这项技术商业化，为需要高扩展性MySQL的企业提供解决方案。

特点：

• 基于Vitess技术的MySQL无服务器平台

• 提供良好的水平扩展能力

• 具有友好的管理界面和SDK

• 相比其他云服务，定价更加实惠

场景：适合需要高度可扩展MySQL数据库的大型应用，特别是面临快速增长的互联网服务。

用法：通过PlanetScale的控制台或CLI工具创建和管理数据库。可以使用熟悉的MySQL客户端或ORM工具连接和操作数据库。

2. YugabyteDB

背景：企业需要一个可以在云环境中无限扩展，同时保留PostgreSQL全部功能的数据库。YugabyteDB填补了这一市场空缺，并通过多云支持解决了供应商锁定问题。

特点：

• PostgreSQL兼容的开源分布式SQL数据库

• 支持多云和混合云部署

• 提供强一致性和高可用性

• 水平扩展能力强

场景：适合需要全球分布式部署的企业级应用，特别是那些重视数据一致性和高可用性的场景。

用法：可以像使用普通PostgreSQL一样使用YugabyteDB，支持标准SQL操作和PostgreSQL生态系统工具。

3. Neon

背景：开发者需要一个现代化、易用且高性能的PostgreSQL云服务。Neon利用Rust语言的优势，提供了零规模扩展等创新特性，以满足这一需求。

特点：

• 基于PostgreSQL的无服务器解决方案

• 支持零规模扩展

• 使用Rust开发，性能优秀

• 支持数据库分支功能

场景：适合需要高性能、低维护成本PostgreSQL数据库的现代化应用，尤其是那些工作负载变化大的场景。

用法：通过Neon的web控制台或API创建和管理数据库。可以使用标准的PostgreSQL客户端连接和操作数据库。

4. Dolt

背景：传统数据库缺乏版本控制功能。Dolt将Git的版本控制理念引入数据库领域，使得数据变更管理变得更加容易和灵活。

特点：

• 结合了MySQL和Git的特性

• 支持数据库分支和版本控制

• 可以比较和合并数据变更

场景：适合需要频繁进行数据实验或需要追踪数据变更历史的场景，如数据科学项目或需要严格审计的金融应用。

用法：可以像使用Git一样创建分支、合并更改，同时支持标准的SQL操作。

5. CockroachDB

背景：大规模分布式系统需要一个能够在全球范围内自动分片和复制的SQL数据库。CockroachDB基于Google Spanner的设计理念，为这一需求提供了开源解决方案。

特点：

• 分布式SQL数据库，支持全球化部署

• 强一致性和高可用性

• 自动分片和负载均衡

• PostgreSQL兼容

场景：适合需要全球化部署、高可用性和强一致性的大规模应用，如金融服务或全球电子商务平台。

用法：可以像使用传统关系型数据库一样使用CockroachDB，支持标准SQL操作。

6. Cloudflare D1

背景：边缘计算的兴起需要一个能在边缘节点运行的轻量级SQL数据库。D1填补了这一空白，并通过JavaScript存储过程创新性地解决了分布式环境下的事务问题。

特点：

• 基于SQLite的边缘数据库

• 与Cloudflare Workers紧密集成

• 支持JavaScript存储过程

• 适合边缘计算场景

场景：适合需要在全球边缘节点快速访问数据的应用，如内容分发网络或低延迟web应用。

用法：通过Cloudflare的开发者平台创建和管理D1数据库，可以在Cloudflare Workers中直接操作数据库。

7. Xata

背景：开发者需要一个结合了关系型数据库强大功能和NoSQL易用性的解决方案。Xata通过电子表格式界面和内置全文搜索满足了这一需求。

特点：

• 无服务器关系型数据库

• 提供类似电子表格的用户界面

• 内置全文搜索功能

• 支持TypeScript和Python SDK

场景：适合需要快速开发和简单数据管理的项目，特别是那些需要全文搜索功能的应用。

用法：通过Xata的web界面或SDK创建和管理数据。可以像操作电子表格一样直观地处理数据。

8. 8base

背景：市场需要一个能够快速构建全栈应用的平台。8base通过提供GraphQL API和低代码工具，简化了后端开发并加速了前端构建过程。

特点：

• 提供GraphQL API的关系型数据库

• 包含低代码工具，可快速构建前端应用

• 后端即服务（BaaS）功能

场景：适合需要快速开发全栈应用的团队，特别是那些偏好GraphQL的项目。

用法：使用8base的低代码工具创建数据模型和API，然后使用GraphQL查询语言操作数据。

9. EdgeDB

背景：传统关系型数据库的表格模型不符合人类思考方式。EdgeDB引入了基于类型的数据模型，使数据建模和查询更加直观。

特点：

• 基于PostgreSQL的图关系数据库

• 使用类型而非表来定义数据模型

• 简化了复杂查询操作

• 提供直观的查询语言

场景：适合需要处理复杂关系数据的应用，如社交网络或知识图谱系统。

用法：使用EdgeDB的查询语言定义数据模型和进行查询，可以通过多种编程语言的客户端库与数据库交互。

10. SurrealDB

背景：开发者需要一个能同时支持关系型、文档型和图数据模型的多模型数据库。SurrealDB提供了这种灵活性，同时保持了良好的性能和可扩展性。

特点：

• 多模型数据库，支持关系型、文档型和图数据模型

• 使用Rust开发，性能优秀

• 支持ACID事务

• 可水平扩展

场景：适合需要处理多种数据模型的复杂应用，如企业资源规划（ERP）系统或复杂的分析平台。

用法：可以使用SurrealQL查询语言进行数据操作，支持多种编程语言的SDK。

11. Fauna

背景：开发者需要一个既易于使用又能支持复杂查询的全球分布式数据库。Fauna结合了文档数据库的简单性和关系型数据库的功能性，填补了这一市场空缺。

特点：

• 全球分布式文档-关系型数据库

• 支持FQL（Fauna Query Language）和GraphQL

• 提供强一致性和ACID事务

• 无服务器架构

场景：适合需要全球化部署、低延迟访问的应用，如实时协作工具或全球化的社交媒体平台。

用法：可以使用FQL或GraphQL查询数据，通过Fauna的控制台或多种编程语言的驱动程序操作数据库。

12. Memgraph

背景：实时数据处理和分析需求的增长。Memgraph针对这一场景优化，提供了比传统图数据库更高的性能。

特点：

• 高性能内存图数据库

• 兼容Neo4j的Cypher查询语言

• 专注于实时数据处理和分析

• 支持流数据处理

场景：适合需要实时图分析的应用，如欺诈检测系统、推荐引擎或网络分析工具。

用法：使用Cypher查询语言操作数据，支持多种编程语言的客户端库。

13. KeyDB

背景：某些应用需要比Redis更高的性能。KeyDB通过多线程设计等创新，在保持Redis兼容性的同时提供了更高的吞吐量。

特点：

• Redis兼容的高性能键值存储

• 多线程架构，提供更高吞吐量

• 支持Active-Active复制

• 可扩展的JavaScript模块系统

场景：适合需要极高性能缓存或消息队列的应用，如高流量网站或实时计分系统。

用法：可以像使用Redis一样使用KeyDB，支持所有Redis客户端和工具。

14. Meilisearch

背景：开发者需要一个易于使用、性能优秀且开源的全文搜索引擎。Meilisearch填补了Elasticsearch和Algolia之间的市场空白。

特点：

• 快速、易用的全文搜索引擎

• 开源，可自托管

• 提供直观的排名和搜索定制选项

• 支持多种语言的客户端库

场景：适合需要快速、准确搜索功能的应用，如电子商务平台、内容管理系统或文档库。

用法：通过RESTful API或客户端库与Meilisearch交互，可以轻松集成到现有应用中。

15. MindsDB

背景：人工智能和机器学习日益普及，需要一种将AI直接集成到数据库中的解决方案。MindsDB简化了ML模型的训练和部署过程，使AI功能更容易集成到现有应用中。

特点：

• 将机器学习模型直接集成到数据库中

• 支持SQL语法进行模型训练和预测

• 可与多种数据库系统集成

• 支持AutoML功能

场景：适合需要在数据库层面集成预测分析的应用，如智能客户服务系统、预测性维护平台或智能决策支持系统。

用法：使用SQL语法创建和训练模型，然后直接在数据库查询中使用这些模型进行预测。

现代数据库范式

通过上述15个数据库的介绍，我们可以看到几个明显的趋势在现代数据库范式中凸显：

1. 无服务器架构：如PlanetScale、Neon和Fauna等数据库采用无服务器架构，简化了数据库管理，提高了可扩展性。

2. 多模型支持：SurrealDB和Fauna等数据库支持多种数据模型，提供了更大的灵活性。

3. 边缘计算支持：Cloudflare D1等数据库专为边缘计算场景设计，满足了低延迟数据访问的需求。

4. 图数据模型：EdgeDB和Memgraph等数据库采用图数据模型，更适合处理复杂的关系数据。

5. AI集成：MindsDB代表了将AI直接嵌入数据库的趋势，简化了机器学习的应用过程。

SQL RDBMS的替代方案

虽然传统的SQL RDBMS仍然有其重要地位，但这些新兴数据库提供了许多有吸引力的替代方案：

1. 改进的可扩展性：CockroachDB和YugabyteDB等提供了比传统RDBMS更好的水平扩展能力。

2. 简化的开发体验：Xata和8base等通过提供直观的界面和强大的API，简化了数据库的使用和管理。

3. 更好的性能：KeyDB等在特定场景下提供了比传统解决方案更高的性能。

4. 更灵活的数据模型：DocumentDB和图数据库提供了比严格的表格模型更灵活的数据存储方式。

人工智能嵌入数据库

MindsDB代表了一个新兴趋势：将AI直接嵌入到数据库中。这种方法有几个显著优势：

1. 简化ML工作流：直接在数据库中训练和使用ML模型，省去了数据导出和模型部署的步骤。

2. 实时预测：能够在查询时实时生成预测，提高了决策的时效性。

3. 数据安全性：避免了数据在不同系统间传输，提高了安全性。

4. 降低门槛：使得非ML专家也能轻松应用AI技术。

结论

数据库技术正在经历一个激动人心的变革时期。从改进的SQL数据库到全新的数据模型，从边缘计算到嵌入式AI，这些创新正在为各种应用场景提供更好的解决方案。虽然传统的SQL RDBMS仍然有其重要地位，但这些新兴数据库正在挑战现状，为开发者和企业提供更多选择。

随着数据量的增长和应用需求的变化，我们可以预期会看到更多的创新。无论是寻求更好的性能、更大的灵活性，还是更简单的使用体验，这些新兴数据库都为我们提供了丰富的选择。在选择数据库时，关键是要根据具体的应用需求和场景来评估各种选项，找到最适合的解决方案。

未来，我们可能会看到更多的融合，如更多数据库原生支持AI功能，或者更多的多模型数据库出现。无论如何，数据库技术的这场革命才刚刚开始，未来还会有更多令人兴奋的发展。

最近比较关注 Local-first AI 技术栈、多模态数据库，Serverless 架构，PayFi 和 DePIN 相关产品，也欢迎随时戳我的收藏夹交流👏 https://web3nomad.notion.site/c4887548177f463e941ad3d8ec92ba0a?v=102f25abed7b8002a8e6000c32f26159

Stable Diffusion web UI

https://github.com/AUTOMATIC1111/stable-diffusion-webui

SD 中有各种各样的模型，除了大模型，还可以搭配其他模型对图片进行微调，这么多模型种类，到底是做什么用的，如何区分呢？不同的基础模型，其画风和擅长的领域会有侧重。

LoRA 训练步骤

LoRA 训练对显卡有一定要求， 同时需要安装一些方便训练的软件。SD1.5 版本的底模 6G 显存勉强可用，8G 显存就可以比较流畅的生成 图片和炼制 LoRA，12G 可以流畅的使用 Dreambooth 微调大模型。

LoRA 训练可以划分为五个步骤：

1. 确定目的

可以简单地划分为两类：具象类和泛化类。

• 具象类：如一个物体、 一种姿态、一种服装、一个人物、某个特定元素等

• 泛化类：如某种场景、某种艺术风格、色彩风格等

2. 收集数据集

「大模型的选择」和「图片质量」都是收集数据集的关键。收集素材阶段，我们仍然按照第一步中的训练目的，分为具象类和泛化类。

注意版权，不要使用有版权的图片，慎用肖像。

3. 数据集预处理

处理数据集包括：优化素材清晰度、统一素材尺寸、生成标签、以及优化标签。

1）批量超分辨率

2）批量剪裁

3）使用 sdwebui 的 tag editor 插件打标

https://github.com/toshiaki1729/stable-diffusion-webui-dataset-tag-editor

安装 Dataset Tag Editor 插件

对比一整段文本的描述，标签适合进行批量的筛选和编辑

配置 tag editor 开始自动打标

输入图片文件夹路径，选择 wd-v1-4-vit-tagger 模型。

点击 "Load" 进行图片加载和自动打标签，右侧的工具可以对标签进行筛选和批量编辑。

点击 "Save all changes" 将标签保存到本地，为每一个图片生成一个对应的 txt 文件，包含了图片的标签，整个文件夹可用于下一步的模型训练。

4）利用 GPT4, GPT4V 和人工进一步调优标签

举个例子：

4. 模型训练

1）配置 LoRA-scripts (SD-Trainer) 工具

下载 https://github.com/Akegarasu/lora-scripts 运行"启动脚本.bat"后，在浏览器打开 http://127.0.0.1:28000/lora/basic.html

参数说明：

• pretrained_model_name_or_path

基础模型的路径，这里可以放 sdwebui 工具里面某个模型的地址

• train_data_dir

训练数据的目录，这里要填写训练数据文件夹的父目录，比如这里的 train/data

然后 train/data 目录下训练数据文件夹命名规则是 [n]_[name]，n 表示文件夹里面的每个图片复制 n 份（适用于数据量较少的情况），name 表示模型的触发词，生成的时候需要在 prompt 中包含这个词

train/data/2_cafe 目录下的内容如上，也就上个阶段 tag editor 插件输出的数据

• output_name

模型的名字，比如 cafe

• output_dir

模型输出的目录，比如 output

• save_every_n_epochs

每隔几个 epochs 保存一个模型的中间结果，比如 2

2）开始训练

训练步数 (Training Steps) = 轮数 (Epochs) * 图片数量。

如果设置了 save_every_n_epochs 则每 n 个 epochs 结束后会保存一个模型，方便后面做效果测试。

如果显卡较大，可以设置 > 1 的批次 (Batch Size)，这样每一步可以同时训练多张图，加快训练。

结合上一步设置的参数，最终输出的模型样例如下，每一个文件就是一个 LoRA 模型。

5. 效果测试

利用 sdwebui 默认集成的 xyz plot 工具 (https://github.com/zer0TF/xyz_plot_script) 可以一次性查看不同 LoRA 权重和不同 Epoch 产生的 LoRA 模型生成的效果，以进一步调优训练参数。

1）准备提示词

借助 MuseAI 的提示词助手，输入需求，生成适合 Stable Diffusion 模型的提示词，稍作微调后可以在 sdwebui 中使用。

2）配置 XYZ Plot 工具

常规的融合 LoRA 模型的方式是在 prompt 中加入 <lora:[name]> 这样的标识，比如这里是使用名字为 “cafe-1” 的 LoRA 模型系列。

使用 XYZ Plot 工具的时候，需要把这个标识改成 <lora:[name]-MODAL:WEIGHT>, 其中 MODAL 和 WEIGHT 是占位符，以便被 XYZ Plot 工具替换成动态的参数。

设置 X/Y 轴的类型为 Prompt S/R，Z 轴的类型不要设置，同时设置 MODAL 和 WEIGHT 的取值。

下面的例子中：MODAL 取值是 000002, 000004, ..., 这个对应前面步骤生成的模型上的 epoch 标记；WEIGHT 的取值是 0.4, 0.6, ..., 1。

3）生成结果

对比不同的 Epoch 里产生的模型及对应的模型权重，看哪个效果是最好的。

点击生成以后，sdwebui 会依次生成多张图，并且在一个平面上展示，例如：

模型的使用

可使用 MuseAI 的的专属模型 - 模型管理，来管理本地训练的 LoRA 模型，并可叠加平台上其他的基础模型或 LoRA 模型进行使用：https://app.museai.cc/

1. 上传模型

2. 分享模型

• 可设置模型的封面图、以及用该模型作画的示例作品

• 以下是一个美妆护肤品的 LoRA 模型分析示例：

https://app.museai.cc/share/model/clktnibkb01qzmj4b2scjbpa2#「Cosmetics」模型分享

3. 使用模型

• 包含所有生成参数，方便其他人一键生成同款

• 可叠加平台上其他的基础模型或 LoRA 模型进行生成

这个 SSH key 用于默认的连接凭证，SSH 客户端需要它来认证身份，而 SSH 服务端需要授权其 public key 的访问权限。

# 生成一对新的 private/public key
ssh-keygen -t rsa -b 4096 -C "ssh@example" -f ./id_rsa
# 输出 base64 格式字符串
cat ./id_rsa | base64
cat ./id_rsa.pub | base64

创建一个集群的 Secret, 运行 `kubectl apply -f ssk-key.yaml`

# 文件名 ssk-key.yaml
apiVersion: v1
kind: Secret
metadata:
  name: ssh-key
type: Opaque
data:
  id_rsa: base64 编码的 id_rsa 文件内容
  id_rsa.pub: base64 编码的 id_rsa.pub 文件内容

构建 SSH server 所需的环境

这里基于 ubuntu:18.04 来构建镜像，只是为了描述必要的安装步骤，实际的基础镜像按照业务需求修改。构建完的镜像在这篇文章中命名为 example/ssh-server:latest

FROM ubuntu:18.04

RUN ln -fs /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

RUN apt update

RUN DEBIAN_FRONTEND=noninteractive apt install -y openssh-server

RUN echo "Port 8022" > /etc/ssh/sshd_config.d/default.conf

RUN echo "AuthorizedKeysFile ~/.ssh/authorized_keys" >> /etc/ssh/sshd_config.d/default.conf

部署

用同一个 Deployment 部署两个容器，实现从一个容器可以 ssh 到另一个容器里。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ssh-client-and-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ssh-client-and-server
  template:
    metadata:
      labels:
        app: ssh-client-and-server
    spec:
      containers:
      - name: ssh-client
        image: ubuntu:18.04
        env:
        - name: HOST_IP
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: status.hostIP
        command: ["/bin/bash", "-c", "while true; do sleep 30; done;"]
        volumeMounts:
        - mountPath: /root/.ssh/id_rsa.pub
          name: ssh-keys
          subPath: id_rsa.pub
        - mountPath: /root/.ssh/id_rsa
          name: ssh-keys
          subPath: id_rsa
      - name: ssh-server
        image: example/ssh-server:latest
        command: ["/bin/bash", "-c", "while true; do sleep 30; done;"]
        ports:
        - containerPort: 8022
        volumeMounts:
        - name: ssh-keys
          mountPath: /root/.ssh/authorized_keys
          subPath: id_rsa.pub
      volumes:
      - secret:
          secretName: ssh-keys
          defaultMode: 0
        name: ssh-keys

一些说明：

• 挂载 Secret 的 id_rsa 和 id_rsa.pub 到 ssh-client 的 ~/.ssh 目录下用于 ssh 登录的凭证

• 挂载 Secret 的 id_rsa.pub 到 ssh-server 的 `/root/.ssh/authorized_keys` 用于允许改 public key 的访问

• ssh-server 的端口是 8022

• ssh-client 容器通过 HOST_IP 环境变量获取 Pod 的 IP

因为两个容器是共享同一个 Pod 的 IP，只是端口不同，在 ssh-client 里可以通过下面的命令 SSH 到 ssh-server 容器里

ssh $HOST_IP -p 8022

搞定。

首先是一个生产流程启动，有点像区块链上有人想要转账，付出小费让人记账，或者是有人想要一个视频，付出一笔金额在 x->A->B 这样一个流程里，每个节点（比如 x），都需要确定自己保留多少收益，并且分给下一个节点（比如 A）多少收益。但是，最终结算，必须是整个流程跑完才会自动结算。越是上游就越要承担让下游能够顺利执行的责任。

执行过程：

1. 每个节点的输入只接收确定性的输入，比如一个具体的文件，一些具体的数值和字符，等等

2. 每个节点的执行过程可以是一个 UDF (user defined function，比如 wasmedge 环境里面的一段脚本)，也可以是一个人工的过程

3. 但每个节点目前只接受确定性的输出，必须通过自动化的测试用例，比如一个图片，要通过某个特定算法识别成文字以后，带有某些标签一大段文字，通过拆分成多个部分分别通过测试用例

但是，测试用例可以共享，所以测试用例其实类似于链上成就系统里面的 credentials。每个人都可以调用其他人的测试用例（或者模型）来收敛自己想要的 output。另外，测试过程也是要成本的，越复杂的测试，就会被这个系统分走更多的利益。系统本身的收益来自于运行这些 UDF 和测试。

测试用例不完备怎么办？

如果 x->A->B->y 这样一条流程里（x和y是起点终点），节点 A 的输出通过测试用例以后进入 B 节点，但其实 A 的节点输出结果对于 B 来说不好，B 就执行不下去。这时候，B 或者其他人，可以重新执行 x->A 的过程，变成 x->A'，同时 A' 向 x 索取更高的利益，然后输出对下游 B' 更有利的数据，形成了一个新的链路 x->A'->B'->C->y。最终只有跑完整个流程的分支才能分享收益。

这个经济系统，通过“上游更好的让下游通过自动化测试”这样的竞争，来确保流程自动执行。为了改变原来甲方语言沟通驱动的无确定性的流程，必须先有一个自动化执行的理想模型，然后对生产关系做一个破坏性的改变，慢慢大家就习惯了。要让越来越多的人参与进来，一定要不断的找到可以逐步融入自动化流程（比如 AI）的节点，在某些场景里，比传统流程跑得快，让这个系统里流转起来的现金越来越多。

对于终端用户来说，它就是一个内容生产的操作系统。

操作系统终端长什么样

控制台里面，就是 N 个不断在生长的有向无环图（起/终点都只有一个），每个图由一系列红绿节点组成，绿色的就是完成了，红色的就是卡住了。任何人都可以继续去 unblock 红色的节点，完成它的任务让它继续生长。unblock 可以通过人工提交数据，也可以直接提交一个 function 自动执行同时任何人都可以重新执行任何其中一个绿色节点的运算，重新和上游分配收益，只要原来的分支没有跑完，新的分支就有可能用更高的效率取胜。

一些思考和补充

这里会出现大量的冗余工作，也就是一个任务会被不同人反复执行，最后只有一个人会取胜。但是社会资源不会造成浪费，如果考虑到我们原来就有的“高效组织的管理成本（包括组织空转、通勤和开会）”也很高。这一点在过去几年 DeFi vs 传统银行，或者 BTC vs 传统货币的讨论中有一些人提出过。虽然暂时无法量化。

关于“上游更好的让下游通过自动化测试”，举个例子 比如要生成一个海报，A->B 的流程里，A 用了 text2image，但是效果不确定好，B 可能就执行不下去了。A 可以花更多成本，输出 1000 张通过一系列测试的图给 B，B 就可以通过简单的人工筛选来输出给它新的下游。

一、升级系统

保持系统处于更新状态是解决此类问题的最佳方案，但如果不便进行完整的升级，请着重升级 openssl，gnutls 和 ca-certificates。 CentOS / RHEL yum upgrade openssl gnutls ca-certificates Ubuntu / Debian apt upgrade openssl libgnutls30 ca-certificates 该解决方案适用于如下平台： Windows >= XP SP3 macOS >= 10.12.1 iOS >= 10 Android >= 7.1.1 Mozilla Firefox >= 50.0 Ubuntu >= xenial / 16.04 Debian >= jessie / 8 Java 8 >= 8u141 Java 7 >= 7u151 NSS >= 3.26

二、手动禁用过期证书

如果系统已不再提供更新，或者不便进行系统更新，可以手动禁用过期证书，具体的操作方案如下： Linux 平台

打开并编辑 /etc/ca-certificates.conf 文件，在 mozilla/DST_Root_CA_X3.crt 这一行前增加一个 ! （感叹号，英文，半角）以禁用该证书，使之变为 !mozilla/DST_Root_CA_X3.crt 编辑完成后，运行 update-ca-certificates 命令以更新系统的证书链。

在 CentOS 7 及其以后的版本

需要执行如下命令：cp /etc/pki/ca-trust/extracted/cadir/DST_Root_CA_X3.pem /etc/pki/ca-trust/source/blacklist update-ca-trust

Windows 平台

使用快捷键 Win + r 并输入 certmgr.msc 以打开系统的证书管理器，搜索 DST ROOT CA X3 并删除相关证书后重启即可。

Java 平台

执行如下命令：sudo keytool -delete -alias dstrootcax3 -cacerts -storepass 'changeit'

def f1(a):
    a.balance = F('balance') + 1
    a.save()
def f2(a):
    a.status = 1
    a.save()
a = Account.objects.create(balance=0, status=0)
with transaction.atomic():
    f1(a)
    ...
    f2(a)

最终数据库里 balance 的值是 2

因为执行 f2 的时候, a.balance 不是一个数值, 依然是一个表达式, f2 中执行 save 会再次对 balance 加 1

避免此类隐藏 bug 的方案是 1). 使用 F 函数更新 Django Model 时, save 以后强制执行一次数据库读取, 即 a.refresh_from_db(), 让 a.balance 变成一个数值 2). save 方法永远都带上 update_fields, 避免更新当前上下文以外的字段, 让 f2 方法提交的 SQL 只更新 status 的值

方案 1 是最保险的, 但个人建议是在大多数情况下, 还是采用方案 2 的编码规范

好久没有在 blog 上写自己擅长的内容了，截止到今天凌晨，互联网上已经有大概6亿8千万张网页，而且依然在迅速增加。今天就来严肃地展开一下网页工程师的话题吧，关于他们的工作，关于他们的职业；关于HTML，关于Python；关于浏览器，关于这个世界。

周围有一些朋友的孩子也快要诞生了，将来可以考虑做个网页工程师呢～

每天的我们，在(还算)安静的办公室里，面对着电脑屏幕，忍受着窗外的喧嚣，随手点开浏览器，输入一段URL，敲下回车键。有没有这样的体验，网站瞬间被打开了，高质量的内容，干净的布局和优秀的设计让你过目难忘。感到吃惊是吧？这一切都归功于一类人，网页工程师，所谓的 Web Developers 们，他们不仅负责网站的搭建和网页的编码，还负责各种测试分析，以及一切和网站相关的维护。

如今网页的重要性毋庸置疑，在商业上，好的网站已经是企业保持竞争力的重要环节。伴随着网页开发技术的日新月异，优秀的网站层出不穷，网页工程师对于自己的工作已经不能有半点马虎，成为一个好的网页工程师也没有任何的捷径。

但问题就来了，正在频繁迭代产品的苦逼创业者们，应该寻找怎样的网页工程师呢？想成为网页工程师却只是刚刚试水HTML和JavaScript或者刚刚开始了解Python和Ruby的童鞋，又应该如何规划自己的技术之路呢？

登录过智联前程大街猎聘周伯通拉勾等等网站，浏览过各类工程师在线课程，接触过网页工程师相关的招聘和应聘的，应该不难发现一个趋势，就是这群人被集中分成了三大类：

前端工程师，后端工程师，全栈工程师

一个一个来说吧

1. 前端工程师 Front-End Developer

和用户发生交互的那一部分叫做网页的前端，说白了它就是你在浏览网页时可以看到的所有东西，字体、颜色、导航栏、下拉菜单、滚动的图片，等等等等，这一切都是由 HTML + CSS + JavaScript 拼装而成，在浏览器的渲染下变得井井有条，很神奇的！

相关技能和工具

前端工程师主要负责网站面向用户部分的代码，以及用户体验相关的架构。一个前端工程师必须熟练地掌握三门基本的语言：HTML，CSS和JavaScript。除此之外，前端工程师还应该熟悉一些样式框架比如Bootstrap和Foundation，和逻辑框架比如Backbone，AngularJS和EmberJS，这些框架确保了网页在不同平台上的质量和稳定性。最后还应该能够熟练的使用一些基本的工具库比如jQuery和SASS/LESS，这些能让开发更加高效，代码更加优质。

另外，很多招聘文案中都会要求求职者有Ajax的开发经验。Ajax技术使用JavaScript默默地和服务器通信来动态加载网页内容，以实现无缝的浏览体验。虽然这不是所有网站都必须的，但这也可以算是前端工程师的基本功之一，毕竟Ajax技术如今也越来越多地被应用到了网页中。

有了前面说的这些技能，前端工程师就可以很好的和设计师合作，和用户体验分析师合作，把草图和原型开发成成品。牛逼的前端工程师还能精确的发现用户体验相关的问题，给出建议和解决方案，用代码来增强设计。一个好的前端工程师还应该能够和业务人员流利的沟通，明白他们的目的，理解他们的需求，了解市场上的机会，并且顺利地执行。

总之在后端工程师造好屋子以后，前端工程师主要负责房屋的内饰。至于房屋的类型和品位，这就取决于房屋的主人了。相比于后端，前端工程师一般来说更加满足于自己的成果，毕竟这是一份技术和创意相结合的工作。经验丰富的前端工程师不仅是一个技术人员，不仅是一个Geek，因为他不仅实现了用户可以看到一切和可以交互的一切，还致力于给用户留下过目不忘的印象，所以他也是一个视觉达人。

那我们看到的网页是怎么来的呢？

再补充一下这个很多人都关心的话题吧，在网页开发过程中，设计师绘制Logo和图像，摄影师拍摄照片，文案编写文字，最后由前端工程师把它们组装在一起，用网页向我们阐释所有内容，用网页向我们提供独一无二的体验，把我们在网站上看到的所有内容变成可能。

体验一下？ 点击打开 http://wedfairy.com 向下滑动页面的过程中上面的 八音盒 导航栏慢慢出现，把鼠标移动到“八音盒故事”的某个案例上面或者用手指按住一个案例，标题就会出现，这些都是前端工程师的功劳。

2. 后端工程师 Back-End Developer

新的问题来了，网页上的数据存在哪里？API又是什么？

就像一间没有造好的屋子，光有室内装饰还是远远不够的。于是我们还需要后端工程师。网页的后端包括服务器，应用程序，以及数据库。这些组件相互作用，使用API和前端通信，确保了网页前端的存在。后端工程师的主要工作就是搭建和维护这些组件。

相关技能和工具

相比于前端开发，后端开发的技术和工具比较多元。为了实现服务器、应用程序和数据库三者之间的通信，后端工程师通常使用Python，Ruby，PHP，Java，.Net等语言来编写应用程序，用MySQL，Oracle，MongoDB来查找、存储和修改数据，然后把它们部署到服务器上来为前端代码提供支持。在实际工作中，后端工程师至少需要掌握一个开发框架，比如PHP的Zend和Symfony，或者Python的Django；还需要能够熟练使用版本控制工具，比如Git和SVN；以及了解Linux开发环境。这些看起来比前端开发枯燥多了！

后端工程师需要使用这些框架和工具来为网站编写优质的代码，有可读性，可移植性，有完备的文档。然而和前端工程师一样，在开始埋头编码以前，后端工程师需要和业务人员充分沟通来理解他们的感性目标，将其转换为技术需求，提出具有可行性的有效方案，来搭建技术架构。

优秀的后端工程师同样热爱自己的工作，沉浸在后端的他们从来不觉得无聊，反而乐在其中。他们喜欢玩弄数据，编写出有用的API，按照不同的权限分配给网页前端、移动应用和其他系统，让前端工程师可以安心的沉浸在交互和布局中。通俗易懂的高质量的API受人尊敬，这就是后端工程师的价值所在。

我们怎样才能感受到后台的存在？

点击 http://qidlove.com 打开婚礼邀请函。此时 八音盒 的服务器会把信息发送到你的手机或电脑中，然后变成你所看到的内容。这就是后台工程师所做的事情。如果你向下滚动屏幕到最后，留下自己的姓名和祝福，点击发送，别人就可以看到你的留言，下一次你再打开这个网页，留言也不会消失，这些都多亏了后端工程师啊！

3. 全栈工程师 Full-Stack Developer

说到这里，首先要明确一点，前端开发和后端开发并不是黑与白的区别，前端工程师和后端工程师之间也没有恐怖分子和反恐精英这样子的暧昧关系。在目前的经济形势下，在这个资源紧缺的市场环境中，前端工程师往往需要学习（至少了解）一些后端开发的技能，反之亦然。产品开发有很多通用的规则，跨越了前后端的界限，于是我们开始寻找一种通才。

它的由来？

全栈工程师自然很早就存在，但是“全栈工程师”的叫法诞生于Facebook的开发部门。四年前，有一类特别的人群被挖掘出来，他们的工作内容涉及到了技术架构（技术栈）中的每一个环节，包括前端和后端，他们可以和后端工程师一样在服务器端玩弄应用程序和数据，也可以使用前端语言控制页面内容和调节用户体验，他们能够提供一套完整的系统。

总之，全栈工程师是网页开发的全能战士。

感觉很酷是吧？成为一个全栈工程师，同时精通前端和后端开发，无形之中给自己的职业生涯创造了很多机会。不过也别高兴得太早，就和烹饪一样，有人更擅长热菜，有人更擅长甜点，精通两者需要时间和经验。妈妈的手艺可不是一日炼成的，更不是简简单单的按照食谱来做就行（事实上很多工程师依然在这样错误的做着）。一个好的全栈工程师和一个好的大厨一样，需要有自己的内涵，需要有所有的烹饪原料，需要掌握所有的方法，才能奉献上一顿完美的晚餐。

相关技能和工具

全栈工程师需要掌握的技能相对复杂，甚至有些主观，因为这不仅仅只是技能相关的需求，而且随着时间的推移，人们对于他们的要求也在一点点变化。除了要根据不同项目掌握前端和后端开发的相应技能外，全栈工程师还需要充分理解网页正常运行的每一个环节，不仅包括合理的服务器配置，规范的API结构，还要通晓JavaScript的哲学，以及CSS背后的设计情怀。

举个栗子，现阶段一个典型全栈工程师的装备，HTML5/CSS3 + Scala + MongoDB + 云服务 + JavaScript

有了知识和技术，就还差经验了，这也是最后一道门槛，全栈工程师尤其需要能够在一个项目面前，快速地定义前端开发和后端开发的职责，分析各种解决方案的优势和劣势，最终选择最合理的执行方式。

老问题，作为用户如何感知网站背后的全栈工程师？

这个我真的说不出来了，自己去感受吧，页面加载需要多久，内容布局是否专业，交互体验是否自然，等等等等。

最后说一句

不要迷恋全栈工程师，任何时间，任何场合，都有一个“大而全”和“小而精”的选择，好的网站从来都不是一个人的功劳，不要忽略了设计师、摄影师、文案、产品经理、客户经理、销售、客服、用户、以及其他所有直接参与和间接参与到网页制作中的人们。识别优秀的工程师也并不一定只是技术层面的事情，无论是前端、后端还是全栈，工程师的自我修养还需要包括对细节的关注，自主学习的速度，解决问题的效率以及良好的沟通能力。

又该说再见了

如果你是个网页工程师，那么恭喜你，你现在最不需要担心的就是找到一份称心的工作，因为至少你可以来我这里，把简历扔过来吧 jobs@wedfairy.com 哈哈。事实上接下来五到十年是网页工程师最好混的时期了，HTML5终于定稿，五花八门的屏幕的出现，跨平台应用的需求越来越高，微信至少还火热着，加油啊！！！

有事没事，请关注这里 @鬼骨孖 的博客 http://blog.ukisama.com

就这样子三个月过去了……9月份发了一条朋友圈消息询问婚礼着装，居然获得了“自从开通朋友圈以来最多的留言数量”，来自世界各地有些熟悉有些不熟悉有些差点忘了名字有些一辈子也忘不了名字的人都来为我“出谋划策”，我意识到这真是一个好兆头啊。

9月底Wedfairy产品上线，刚刚登上CEO宝座的西北人肉们李回天水。第二天，另一个创始人西北人小钊来办公室，主要是来和我说左姑娘和默姑娘的故事，随后我发现自己从零时区到西八区的各个朋友圈终于被打通了。接下来我要为五湖四海的你们讲一下我自己的故事。

10月份去三番原本是为了接一个基友回来一起在上海把Wedfairy做好。我原以为自己说教的功力还没有减弱，基友笑了，他说他要十一月自己一个人回来，连自己的妈妈也不告诉。我觉得在硅谷待久了真的会变的莫名其妙，还是加入我们好。

到目前为止，已经打了三个广告（具体是哪三个可以在八音盒婚礼邀请函公众号里留言，答对没有任何形式的奖励）。

Wedfairy有一个老派又时髦的中文名字，八音盒，他还有一个修饰语，“会讲故事的婚礼邀请函”。这是继大麦盒（还记得华盛顿的那盒牛奶吗？）以后又一个出现在本博客中的产品，于是“盒子计划”已经完成了三分之二。八音盒倡导婚礼邀请函中的主角都是新郎和新娘最真实的自己，每一场婚礼背后都有数不清埋在主角心中很久的故事，所有故事汇集在一起就组成了这张独一无二的婚礼邀请函。所有使用八音盒制作婚礼邀请函的人们都在向全世界宣告一条充满正能量的信息，它看似短暂，却是永恒。它影响到的范围远远超过了新人的想象，它让人们越来越热衷于去发现生活中的美好，乐于去表达自己的快乐，与全世界每一个角落的小伙伴们一起创造一张最有创意的地图。

事实上现在Wedfairy的人就是这么工作的。

1. 离开自己的公司

Wedfairy现在的总人数是个质数，除了两个85后，其他都是兼职，他们来自上海，北京，深圳，旧金山，巴黎，新加坡，但是他们一个一个接着一个一个的离开了或者准备离开自己原来的公司。

但这不代表我们已经满员了，如果你想加入我们，请猛击这里 http://wedfairy.com (或者点击下方"查看原文") 讲一个自己的故事，然后告诉我们。如果你在上海，很幸运你可以直接过来，沿着黄浦江游到北面，我们在杨浦大桥脚下，看着红色的桥身会有种在旧金山的错觉。如果你不在，你最好选择环保的交通工具过来，我们报销路费和住宿，以及其他服务的费用（哇哈哈～）

2. 每天做一件可以写进日记的事情

古人鬼骨孖有一句名言，翻译过来大概是说，人写日记，不是为了把本子填的满满的，而是为了督促自己把生活填的满满的。我觉得很有道理，于是我们大家都这么做。KickStarter上有不少项目，它们设计和产品做的很不好，但着实可以打动人，其中一个叫做 One Second Every Day，这些作者们被放大的理想就是我们拿来约束自己的底线。

无论是郁金香血洗斗牛士，还是陪着人家的女朋友吹海风，或是发现办公室突然多出来一百箱水，这些都是值得被记录的事情。

3. 为每一天都打上标签

我们在为别人谱写故事，就要先让自己的生活充满故事。除了每天喝水走路呼吸空气，还有什么可以督促自己把生活填充的满满的呢？

创始人用自己的故事感动了身边的人以后，又开始倒弄了。他（其实就是我啦）正在和自己的妻子执行一个神秘的计划，Count The Day

他们的一周是这样子的：

周一是 Free Day 随便做什么 周二是 Cooking Day 必须回家做饭吃 周三是 Walking Day 要出去散步 周四是 Reading Day 晚上要看书 周五是 Low Carbon Day 要坐地铁上下班 周六是 Running Day 要去跑步 周日是 Explore Day 要去任何一个以前从没去过的地方

事实上，天变冷了，他们最近并没有好好的执行。

4. 自己的事情自己做

Wedfairy的每一个人每天都在创造着故事。自己的事情自己做，不光是工作上的，还有生活上的。大家把责任看作是保证整个团队充满能量的必要条件，我们因此感到自己无比幸运。尤其是在我们这样扁平化管理的团队中，生活琐事的主动分担让每一个人都能真正感觉到自己工作在一个轻松快乐的环境中。

我们每天早上轮流去楼下的全家便利店带最便宜的咖啡，每天下午轮流下楼穿过庞大的广场舞团体去体验最本地化的生活。我们喜欢分享同一个批萨，也明白在绿茵场上各司其职。

事实上，一段时间以后，等到团队越来越完整了，CEO的首要职责就是每天打扫卫生了，这可以让我们的生活成本大大降低。至于拿着最低工资的CTO？他负责做每天一百万次手动点击的“猴子测试”，以及在这里发博客。

5. 消除一切干扰

我们一直在寻找一种方式，让自己消除干扰，提高整体的效率。回忆起曾经一边看美剧一边写程序，或者一边玩游戏一边画流程图的年代，简直是颓废到了极点。如今变专业了，我们时常展开连续的头脑风暴安排高质量的咖啡时间，这让我们快速的建立起强大的社交和学习节奏，但我们依然想方设法的让自己专注于产品制作。作为初创企业，在我们这个阶段，给自己多一些时间研究产品，给自己多一点机会和用户沟通，对我们来说弥足珍贵，当然也是最好不过的事情啦。

6. 保持身体健康

尽管这只是一个生活方式的话题，但保持身体健康不仅仅是工作效率的保证，也是一种对团队负责的态度。尽管有时候我们会从太阳下山奋战到太阳升起，我们也不会一直坐在椅子上盯着50cm外的屏幕，我们杜绝一切背部酸痛，颈椎麻木，眼睛疲劳，体重增加，等等等等让自己的自拍照越来越难看的隐患。

每晚的充足睡眠，每天的步行时间，每周的运动时间，做不到的，不是因为太努力，而是跟不上我们的节奏。

7. 别丢了自己的创作情怀

最后的最后，想了解八音盒的诞生，请关注我们上一篇微信公众号文章 >>> 寻找那遗失的创作情怀

有事没事，请关注这里 @鬼骨孖 的博客 http://blog.ukisama.com

接下来一个月里，两个不可忽视的功能最终出现在了新产品中

1. 读者可以在祝福的时候留下自己的姓名，目前只有故事制作者可以在工具中看到留言者的姓名

2. 增加了留言审核的功能，在工具中可以把不喜欢的、过火的、毫无意义的留言隐藏

3. 添加音乐，万众期待，终于上线！

拿出你压箱底的好情歌，感动那些陌生或不陌生的情侣

十月中旬去旧金山转了一圈，一号公路一路向南，一个礼拜里把硅谷的朋友们见了一圈，终于，最后，在月底的时候，门飞重磅回国了，任务完成吧。

有事没事，请关注 @鬼骨孖 的博客

拉布拉多最终没有入手，看来要等到冬天再说了。九月发生了太多的事情，急冲冲的来回北京，颗粒无收，遇到了当年孟痣门下的一位学姐，又见到了白姑娘和她的梗，心里平衡不少。中秋节回家的路上相对有趣，两个人一起回家就是好，在车上可以轮流朗读，读完了诺冬的《闻所未闻》，居然做了个足以影响八音盒所有人好多年的重大决定，随后很脑残的买来《广岛之恋》的剧本，敦促自己快些定下日本的行程。

言归正传

1. 计时器终于上线！新制作的故事中都会出现“倒计时”或者“时间流逝”

2. 所有故事底部又重新加入了 MADE WITH LOVE 字样

3. 在不少新人的要求下，发送祝福留言是可以留下姓名，但不会公开

4. DIY工具上做了好多修修补补，非常欢迎各种反馈和报错～

5. 新版主页上线！两个人用了一周时间东拼西凑的做出了一个感觉还不错的主页，像模像样的～建议在PC上浏览。。

6. 其他一些变化，肉们李得到一个新技能。

变化无常的九月终于过去了，欢迎更加变幻莫测的十月吧～国庆快乐！十一期间要见雪上阳，有些激动。

有事没事，请关注 @鬼骨孖 的博客

过去的一周团队还正式搬进了新办公室，装上了电信的宽带，锁定了一家有优质现磨咖啡的便利店，发现了一家有纯正陕西口味的面馆，好像还一起玩了一局FIFA

言归正传

1. 计时器和心愿单模块看起来没法按时推出 看来要等到一周后啦。

2. 移除了所有故事最后的尾页，统一在顶部Banner呈现八音盒的logo和名字。

3. 改良照片上传，减少了冗余的步骤，值得一试！

4. 分离注册和登录页面，解决部分用户觉得理解困难的问题。

5. 工具中主题切换页面中的每一个主题都配上形象的图，代替难以理解的色块。

6. 引导页面的每一步也配上了图。

7. 每一个故事模块制作完可以直接进入下一个模块。

8. 做完第一份宣传小册子，婚博会遇到好大的挫折，城管保安无处不在，第一次集体线下递推失败。

9. 这一周团队重新联系了种子用户，A/B测试看起来很成功。看来好多用户对于故事场景的认知以及文字的思索还有很多问题。

八月结束前，确定了第一笔资金，快乐的迎来金秋九月。

请继续期待计时功能，更方便直观的文字启发，产品介绍和全新主页也将面世！

有事没事，请关注 @鬼骨孖 的博客

在接下来的一周里，八音盒产品团队致力于解决了如下问题：

1. 新故事由原型故事产生，代替无图无文字的空故事

2. 相册模块可以添加、删除和替换照片

3. 全新的主页，更详细的产品介绍，更多案例，更好的留言板

4. 故事引导中，每个模块的输入顶端都加入超大的“启发”按钮

5. 可以编辑分享出去的故事标题和故事概述，目前适用于微信分享

6. 增加两个新模板 oldtimes 和 ladypink

7. 在客户端自动缩放用户上传的图片，加快上传速度，减少存储空间

8. 开场白和地址可以多行输入

9. 地图模块中可以直接使用百度地图，也可以自己上传地图

10. 在PC上打开工具和故事页面，使用 iFrame 模拟手机上打开的样式，并有手机扫描二维码提示

下周新功能预告：

计时和心愿单，更方便的分享功能，敬请期待！！！

有事没事，请关注 @鬼骨孖 的博客

七个月后浦东，从陆家嘴一路向南，我和小猴时隔多年再次站在一部公交车里。小猴说门飞是个坏(shǎ)蛋(bī)，不但弄破了他的爱车，还在写程序的时候开着另一个屏幕看美剧，看完一集写五分钟继续看下一集。

回家以后我坐下来回忆离开陋(fù)室(dàn)后的四年，心想一直没有变的何止是我。

我们陋室出来的少(diǎo)年(sī)可能永远都不会变了。我们从不缺少创意，却没有脚踏实地的本领。我们又把创意看的一文不值，让矛盾的自己无法立足。我们喜欢和他人分享喜悦，到最后独自在墙(lóu)角(xià)啜(tī)泣(qiú)。

我无时无刻不想回到过去，只可惜大家都说物是人非。挂靴两年，头一次买了新足球，暂时就家里玩玩。FIFA从来舍不得给自己买正版，因为这实在是太与时俱进。曾经一天一次的事情到现在都是一年一次，曾经见了都心烦的人如今连张合照都需要合成。

勉强让人开心的是周末做的事情差不多，在复旦，本地的学生周末可以回家，他们就是传说中高贵的走读生，剩下楼里没几个人，于是大家双休日不是吃饭就是写程序。如今竟然也一样，还有那些罗宾李手下的高级程序语言们，端午节都要跑公司去敲打键盘。

我突然又明白了个事儿(北京腔)，现在那些看着很有责任感不辱使命完成任务最爱强调自我价值多愁善感勇于直面惨淡人生的人们，怕是心里闷得慌。自欺欺人的事情太多了，创业者们口口声声说要创造美好的世界，电梯里倒经常一股烟味儿(再一次北京腔)，这样的生活很COOL吗(好酷哦!)。我曾经在别人卧室里吸完一包也没有让眼前的代码更COOL(好酷哦!)，一直以来我都瞧不起自己那段堕落的时光，可笑的是我那时候真的很开心。为什么？

有空去研究过去，不如快些从头再来。

去年的三个新年愿望实现了一个，今年希望有好运。今年的三个愿望更加温柔些，当一次导演，潜规则一个女主角，载着CEO去兜风。

2014 A TOUGH YEAR @鬼骨孖